26

This is stated in the man page for systemd-nspawn

Note that even though these security precautions are taken systemd-nspawn is not suitable for secure container setups. Many of the security features may be circumvented and are hence primarily useful to avoid accidental changes to the host system from the container. The intended use of this program is debugging and testing as well as building of packages, distributions and software involved with boot and systems management.

This very question was subsequently asked on the mailing list in 2011, but the answer seems to be outdated.

systemd-nspawn contains code to execute CLONE_NEWNET using the --private-network option now. This seems to cover the private AF_UNIX namespace issue, and I guess the CAP_NET_RAW and CAP_NET_BIND issues mentioned.

What issues remain at this point and what does for example LXC do in addition to what systemd-nspawn can currently do?

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
user239558
  • 405
  • 1
  • 4
  • 7
  • AF_UNIX gets half-isolated with `CLONE_NEWNET`: abstract sockets - separate, filesytem-based - united (unless there are no shared filesystems between host and container). This makes convenient to start X applications barring network for particular application (as Xorg opens both abstract and filesystem UNIX socket). – Vi. Sep 03 '14 at 01:26
  • The statement that nspawn is "unsuitable for secure container setups" was removed in 2016: https://github.com/systemd/systemd/pull/3577 From the man page it appears that nspawn is production-ready and has been for a few years. – Pyfisch Sep 18 '22 at 11:58

1 Answers1

12

LXC is a little bit better because it can run containers as unpriveleged users. This is possible with systemd-nspawn, but only for scenarios where you only need one user (instead of multiple), which can be difficult or less secure for multi process in container scenarios. If you want to know why docker, lxc, and systemd-nspawn are inherently not a solid security mechanism, read this: https://opensource.com/business/14/7/docker-security-selinux. Basically, containers still have access to the kernel and any kernel exploit gains control of the entire machine. On a monolithic kernel like Linux, kernel exploits are not uncommon.

CameronNemo
  • 1,133
  • 9
  • 19
  • 3
    This answer is incorrect. systemd-nspawn supports dropping privileges to a different user: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html – David Timothy Strauss Oct 17 '14 at 13:08
  • I am pretty sure all that does is run the console / shell as a non-priveleged user, but run everything else as root. Can you look into that? – CameronNemo Oct 17 '14 at 22:13
  • 1
    Ok, I take my last statement back. However, it does not have proper subuid/subgid handling, only one unpriveleged user per container. – CameronNemo Oct 17 '14 at 23:53
  • 3
    Only being able to drop to one unprivileged user per container instead of supporting full subuid/subgid handling isn't a security issue. It's a feature limitation. – David Timothy Strauss Oct 19 '14 at 04:20
  • Yeah, I know. I was just pointing out the difference. – CameronNemo Oct 20 '14 at 00:01
  • @DavidTimothyStrauss That was a great link. The sense I'm making of the whole situation is that containers isolation is only for benign processes. And if a malignant program is running in the container as root, think of it's privileges being the same as a malignant root program on the host machine. With VM's it's multiple layers of security- root or not. One question- say I run postgres and http server as two different containers owned by two different unprivileged users. Is this any more secure than running the same as two different unprivileged users on the host machine itself? – 0fnt Oct 26 '19 at 07:00
  • I would recommend referencing https://people.kernel.org/brauner/runtimes-and-the-curse-of-the-privileged-container for further evaluation of how uid namespaces limit the severity of vulnerabilities. – CameronNemo Oct 27 '19 at 04:02