- 14 Feb, 2019 2 commits
-
-
Christian Brauner authored
My first attempt to simplify this and make it less costly focussed on the way constructors are called. I was under the impression that the ELF specification mandated that arg, argv, and actually even envp need to be passed to functions located in the .init_array section (aka "constructors"). Actually, the specifications is (cf. [2]): SHT_INIT_ARRAY This section contains an array of pointers to initialization functions, as described in ``Initialization and Termination Functions'' in Chapter 5. Each pointer in the array is taken as a parameterless procedure with a void return. which means that this becomes a libc specific decision. Glibc passes down those args, musl doesn't. So this approach can't work. However, we can at least remove the environment parsing part based on POSIX since [1] mandates that there should be an environ variable defined in unistd.h which provides access to the environment. See also the relevant Open Group specification [1]. [1]: http://pubs.opengroup.org/onlinepubs/9699919799/ [2]: http://www.sco.com/developers/gabi/latest/ch4.sheader.html#init_arraySigned-off-by:
Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
The ELF binary spec does specify in [1]: SHT_INIT_ARRAY This section contains an array of pointers to initialization functions, as described in ``Initialization and Termination Functions'' in Chapter 5. Each pointer in the array is taken as a parameterless procedure with a void return. which means libcs other than glibc might not pass down argc and argv to constructors. This reverts commit 0c816b34. [1]: http://www.sco.com/developers/gabi/latest/ch4.sheader.html#init_arraySigned-off-by:
Christian Brauner <christian.brauner@ubuntu.com>
-
- 13 Feb, 2019 2 commits
-
-
Stéphane Graber authored
rexec: remove needless /proc/cmdline parsing
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
- 12 Feb, 2019 6 commits
-
-
Stéphane Graber authored
apparmore: Improve testing on apparmor python script
-
Hervé Beraud authored
Compare command output to already existing container-rules file Signed-off-by:Hervé Beraud <hberaud@redhat.com>
-
Stéphane Graber authored
apparmor: catch config file opening error
-
Hervé Beraud authored
Improve config file error opening management and improve main code block. Execute this python script during CI to avoid regressions Signed-off-by:Hervé Beraud <hberaud@redhat.com>
-
Stéphane Graber authored
rexec: make rexecution opt-in for library callers
-
Christian Brauner authored
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>
-
- 11 Feb, 2019 14 commits
-
-
Stéphane Graber authored
string_utils.h: fix wrong licensing
-
Christian Brauner authored
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> Signed-off-by:
Christian Brauner <christian.brauner@ubuntu.com> Acked-by:
Fabrice Fontaine <fontaine.fabrice@gmail.com> Acked-by:
Josh Soref <jsoref@gmail.com>
-
Stéphane Graber authored
fix licensing headers
-
Christian Brauner authored
/* Affected People */ Christian Brauner <christian.brauner@ubuntu.com> Aleksa Sarai <cyphar@cyphar.com> Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
/* Affected People */ Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
/* Affected People */ Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
/* Affected People */ Christian Brauner <christian.brauner@ubuntu.com> Aleksa Sarai <asarai@suse.de> Signed-off-by:
Christian Brauner <christian.brauner@ubuntu.com> Acked-by:
Aleksa Sarai <cyphar@cyphar.com>
-
Christian Brauner authored
/* Affected People */ Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
/* Affected People */ Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
/* Affected People */ Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
/* Affected People */ Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Stéphane Graber authored
include: add fexecve() for Android's Bionic
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
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>
-
- 10 Feb, 2019 6 commits
-
-
Stéphane Graber authored
parse: handle \r
-
Christian Brauner authored
Closes #2838. Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Wolfgang Bumiller authored
cgroup: bugfixes
-
Christian Brauner authored
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: d97919ab ("cgroups: partially switch to cleanup macros") Reported-by:
Stéphane Graber <stgraber@ubuntu.com> Signed-off-by:
Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
- 09 Feb, 2019 10 commits
-
-
Stéphane Graber authored
coccinelle support
-
Stéphane Graber authored
caps: check uid and euid
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
bugfixes
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-