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.
Rachid Koucha [Sun, 27 Jan 2019 02:38:36 +0000 (03:38 +0100)]
Installation of default.script for udhcpc
The busybox template installs default.script in /usr/share/udhcpc/.
But the pathname of "default.script" may vary from one busybox
build to another. As the pathname is displayed in udhcpc's help,
grab it from it.
Rachid Koucha [Sat, 26 Jan 2019 23:10:39 +0000 (00:10 +0100)]
Avoid risk of "too far memory read"
As we call "lxc_add_state_client(fd, handler, (lxc_state_t *)req->data)"
which supposes that the last parameter is a table of MAX_STATE
entries when calling memcpy():
memcpy(newclient->states, states, sizeof(newclient->states))
fix: unprivileged veth devices (e.g. vethFWABHX) never contain 'Z' character in the randomly generated device name part because for modulo one does not need to substract 1 from strlen().
SIGWINCH is handled in lxc_terminal_signalfd_cb().
I cannot for the life of me figure out what this is supposed to do.
Afaict, it scans a global list that is totally unnecessary and also
let's say you have 100 ttys and for a single one SIGWINCH is sent. In
that case the whole list is walked and two ioctl()s are performed: one
to get window size one to set window size. For 99 of them the window
size hasn't changed.
If we see issues we can revert!
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Compiler based hardening (including -fstack-protector-strong) are
enabled since version 3.0.3 and
https://github.com/lxc/lxc/commit/2268c27754152aa538db2c9e3753d72d19bcd17a
However, some compilers could missed the needed library (-lssp or
-lssp_nonshared) at linking step so use ax_check_link_flag instead of
ax_check_compile_flag
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.
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>
RW bind mounts need to be restricted for some paths in
order to avoid MAC restriction bypasses, but read-only bind
mounts shouldn't have that problem.
Additionally, combinations of 'nosuid', 'nodev' and
'noexec' flags shouldn't be a problem either and are
required with newer systemd versions, so let's allow those
as long as they're combined with 'ro,remount,bind'.
projects / thirdparty / lxc.git / log
