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?

2
  • 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 3, 2014 at 1:26
  • The statement that nspawn is "unsuitable for secure container setups" was removed in 2016: 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, 2022 at 11:58

1 Answer 1

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.

7
  • 3
    This answer is incorrect. systemd-nspawn supports dropping privileges to a different user: freedesktop.org/software/systemd/man/systemd-nspawn.html Oct 17, 2014 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? Oct 17, 2014 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. Oct 17, 2014 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. Oct 19, 2014 at 4:20
  • Yeah, I know. I was just pointing out the difference. Oct 20, 2014 at 0:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .