5 ms·

Does someone know how this would be manually applied to systemd-nspawn containers? Beside a kernel bug, what are the things a root process in a container could

• andor 11y ago
  The systemd-nspawn man page has an example that might help: Example 6. Run a container with SELinux sandbox security contexts # chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R \ /srv/container # systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 \ -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container \ /bin/sh In addition to -Z and -L, there's also --drop-capability. Apart from privilege escalation bugs, any shared resource can theoretically be used to escape containers. For example, access to main memory via a device with DMA, access to the same /proc as the host, access to a shared filesystem (replace a binary that the host executes), etc.
• SEJeff 11y ago
  The same thing a root user inside of a chroot can do... break out of the namespace and make it into the host system, as root. http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/ http://www.projectatomic.io/blog/2014/09/yet-another-reason-... http://opensource.com/business/14/7/docker-security-selinux http://opensource.com/business/14/7/docker-security-selinux