We cannot rexecute the liblxc shared library unconditionally as this would
break most of our downstreams. Here are some scenarios:
- anyone performing a dlopen() on the shared library (e.g. users of the LXC
Python bindings)
- LXD as it needs to know the absolute path to its own executable based on
/proc/self/exe etc.
This commit makes the rexecution of liblxc conditional on whether the
LXC_MEMFD_REXEC environment variable is set or not. If it is then liblxc is
unconditionally rexecuted.
The only relevant attack vector exists for lxc-attach which we simply reexecute
unconditionally.
Reported-by: Stéphane Graber <stgraber@ubuntu.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
liblxc has always been meant to be LGPLv2.1+ as reflected by the many
downstreams projects and bindings which are themselves under LGPLv2.1+ or other
licenses which would be incompatible with linking against a GPLv2+ library.
It's pretty normal for a library to be LGPL while binaries are GPL as a GPL
library would only ever be usable by other GPL-only projects, which isn't the
case for very many of the liblxc downstreams.
The issue here is really carelessness. None of those GPL headers were put there
intentionally, instead being wrongly copy/pasted from other parts of the
codebase which is indeed intended to be GPLv2+. This is also made clear in our
CONTRIBUTING file in this repository:
Licensing for new files:
------------------------
LXC is made of files shipped under a few different licenses.
Anything that ends up being part of the LXC library needs to be released
under LGPLv2.1+ or a license compatible with it (though the latter will
only be accepted for cases where the code originated elsewhere and was
imported into LXC).
Language bindings for the libraries need to be released under LGPLv2.1+.
Anything else (non-libraries) needs to be Free Software and needs to be
allowed to link with LGPLv2.1+ code (if needed). LXC upstream prefers
LGPLv2.1+ or GPLv2 for those.
When introducing a new file into the project, please make sure it has a
copyright header making clear under which license it's being released
and if it doesn't match the criteria described above, please explain
your decision on the lxc-devel mailing-list when submitting your patch.
This is intended to switch over files to LGPLv2.1+ to which end we have
collected ACKs from relevant people.
/* Affected People */
Christian Brauner <christian.brauner@ubuntu.com>
Fabrice Fontaine <fontaine.fabrice@gmail.com>
Josh Soref <jsoref@gmail.com>
Adam Iwaniuk and Borys Popławski discovered that an attacker can compromise the
runC host binary from inside a privileged runC container. As a result, this
could be exploited to gain root access on the host. runC is used as the default
runtime for containers with Docker, containerd, Podman, and CRI-O.
The attack can be made when attaching to a running container or when starting a
container running a specially crafted image. For example, when runC attaches
to a container the attacker can trick it into executing itself. This could be
done by replacing the target binary inside the container with a custom binary
pointing back at the runC binary itself. As an example, if the target binary
was /bin/bash, this could be replaced with an executable script specifying the
interpreter path #!/proc/self/exe (/proc/self/exec is a symbolic link created
by the kernel for every process which points to the binary that was executed
for that process). As such when /bin/bash is executed inside the container,
instead the target of /proc/self/exe will be executed - which will point to the
runc binary on the host. The attacker can then proceed to write to the target
of /proc/self/exe to try and overwrite the runC binary on the host. However in
general, this will not succeed as the kernel will not permit it to be
overwritten whilst runC is executing. To overcome this, the attacker can
instead open a file descriptor to /proc/self/exe using the O_PATH flag and then
proceed to reopen the binary as O_WRONLY through /proc/self/fd/<nr> and try to
write to it in a busy loop from a separate process. Ultimately it will succeed
when the runC binary exits. After this the runC binary is compromised and can
be used to attack other containers or the host itself.
This attack is only possible with privileged containers since it requires root
privilege on the host to overwrite the runC binary. Unprivileged containers
with a non-identity ID mapping do not have the permission to write to the host
binary and therefore are unaffected by this attack.
LXC is also impacted in a similar manner by this vulnerability, however as the
LXC project considers privileged containers to be unsafe no CVE has been
assigned for this issue for LXC. Quoting from the
https://linuxcontainers.org/lxc/security/ project's Security information page:
"As privileged containers are considered unsafe, we typically will not consider
new container escape exploits to be security issues worthy of a CVE and quick
fix. We will however try to mitigate those issues so that accidental damage to
the host is prevented."
To prevent this attack, LXC has been patched to create a temporary copy of the
calling binary itself when it starts or attaches to containers. To do this LXC
creates an anonymous, in-memory file using the memfd_create() system call and
copies itself into the temporary in-memory file, which is then sealed to
prevent further modifications. LXC then executes this sealed, in-memory file
instead of the original on-disk binary. Any compromising write operations from
a privileged container to the host LXC binary will then write to the temporary
in-memory binary and not to the host binary on-disk, preserving the integrity
of the host LXC binary. Also as the temporary, in-memory LXC binary is sealed,
writes to this will also fail.
Note: memfd_create() was added to the Linux kernel in the 3.17 release.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Co-Developed-by: Alesa Sarai <asarai@suse.de> Acked-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
When cgroup creation failed we reset container_cgroup to NULL to avoid
issues with __cleanup__. Fix that logic:
- add steal_ptr() based on take_ptr()
- move stealing the pointer out of the loop
lxc ctImport 20190210050705.858 DEBUG network - network.c:instantiate_veth:202 - Instantiated veth "vethGQMH7I/vethSPXNL3", index is "272"
lxc ctImport 20190210050705.858 ERROR cgfsng - cgroups/cgfsng.c:mkdir_eexist_on_last:1262 - File exists - Failed to create directory "/sys/fs/cgroup/unified//lxc.payload/ctImport-0"
lxc ctImport 20190210050705.858 ERROR cgfsng - cgroups/cgfsng.c:container_create_path_for_hierarchy:1302 - Failed to create cgroup "/sys/fs/cgroup/unified//lxc.payload/ctImport-0"
lxc ctImport 20190210050705.858 ERROR cgfsng - cgroups/cgfsng.c:cgfsng_payload_create:1431 - Failed to create cgroup "/sys/fs/cgroup/unified//lxc.payload/ctImport-0"
lxc ctImport 20190210050705.858 INFO cgfsng - cgroups/cgfsng.c:cgfsng_payload_create:1441 - The container uses "lxc.payload/ctImport-0" as cgroup
lxc ctImport 20190210050705.858 ERROR cgfsng - cgroups/cgfsng.c:mkdir_eexist_on_last:1262 - File exists - Failed to create directory "/sys/fs/cgroup/unified/"
lxc ctImport 20190210050705.858 ERROR cgfsng - cgroups/cgfsng.c:container_create_path_for_hierarchy:1302 - Failed to create cgroup "/sys/fs/cgroup/unified/"
lxc ctImport 20190210050705.858 ERROR cgfsng - cgroups/cgfsng.c:cgfsng_payload_create:1431 - Failed to create cgroup "/sys/fs/cgroup/unified/"
lxc ctImport 20190210050705.858 INFO cgfsng - cgroups/cgfsng.c:cgfsng_payload_create:1441 - The container uses "(null)" as cgroup
Fixes: d97919abf22 ("cgroups: partially switch to cleanup macros") Reported-by: Stéphane Graber <stgraber@ubuntu.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
When we are running inside of a user namespace getuid() will return a
non-zero uid. So let's check euid as well to make sure we correctly drop
capabilities
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Warn whenever a local variable or type declaration shadows another
variable, parameter, type, class member (in C++), or instance variable
(in Objective-C) or whenever a built-in function is shadowed.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Warn whenever a function is defined with a return type that defaults to
int. Also warn about any return statement with no return value in a
function whose return type is not void (falling off the end of the
function body is considered returning without a value).
For C only, warn about a return statement with an expression in a
function whose return type is void, unless the expression type is also
void. As a GNU extension, the latter case is accepted without a warning
unless -Wpedantic is used.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Rachid Koucha [Tue, 29 Jan 2019 11:20:46 +0000 (12:20 +0100)]
More accurate error msg for template file
When calling lxc-create, if the template exists but is not executable, we end with the following error messages which make believe that the template file does not exist when it is merely a execute access problem:
lxc-create: ctn00: utils.c: get_template_path: 918 No such file or directory - bad template: /.../lxc-busybox
lxc-create: ctn00: lxccontainer.c: do_lxcapi_create: 1786 Unknown template "/.../lxc-busybox"
lxc-create: ctn00: tools/lxc_create.c: main: 327 Failed to create container ctn00
Actually internally the errno is lost as the following code triggers a useless access to (strace output):
access("/.../lxc-busybox", X_OK) = -1 ENOENT (No such file or directory)
With the above fix, we get a more explicit error message when the template file is missing the "execute" bit:
lxc-create: bbc: utils.c: get_template_path: 917 Permission denied - Bad template pathname: /tmp/azerty
lxc-create: bbc: lxccontainer.c: do_lxcapi_create: 1816 Unknown template "/tmp/azerty"
lxc-create: bbc: tools/lxc_create.c: main: 331 Failed to create container bbc
With the above fix, we get a more explicit error message when the pathname of the template file is incorrect:
lxc-create: bbc: utils.c: get_template_path: 917 No such file or directory - Bad template pathname: /tmp/qwerty
lxc-create: bbc: lxccontainer.c: do_lxcapi_create: 1816 Unknown template "/tmp/qwerty"
lxc-create: bbc: tools/lxc_create.c: main: 331 Failed to create container bbc
Rachid Koucha [Sun, 27 Jan 2019 12:46:48 +0000 (13:46 +0100)]
/etc/resolv.conf grows indefinitely
This file grows indefinitely : upon each DHCP lease renew,
the "nameserver ..dns..." line is added at the end of the file.
Make a "grep" in the file to make sure that the same line
does not already exist.
projects / thirdparty / lxc.git / log
