Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
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 at 1:26

1 Answer 1

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.

share|improve this answer
    
This answer is incorrect. systemd-nspawn supports dropping privileges to a different user: freedesktop.org/software/systemd/man/systemd-nspawn.html –  David Timothy Strauss Oct 17 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 at 22:13
    
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 at 23:53
    
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 at 4:20
    
Yeah, I know. I was just pointing out the difference. –  CameronNemo Oct 20 at 0:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.