[systemd-devel] What makes systemd-nspawn "not suitable for secure container setups"?

[Lennart Poettering]

On Fri, 22.04.11 21:16, Josh Triplett (josh at joshtriplett.org) wrote:

> On Sat, Apr 23, 2011 at 11:28:58AM +0800, microcai wrote:
> > 于 2011年04月23日 10:55, Josh Triplett 写道:
> > > The systemd-nspawn manpage lists the various mechanisms used to isolate
> > > the container, and then says "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."
> > > 
> > > How can a process in a systemd-nspawn container circumvent the container
> > 
> > remount /proc and /sys
> 
> Ah, good point.  So, root inside the container can trivially circumvent
> the container that way.  Any way to prevent that with current kernel
> support, or would fixing this require additional kernel changes to lock
> down other /proc and /sys mounts?

Yes, by dropping CAP_SYS_ADMIN for the container. 

As mentioned we could do that probably, but there are a lot of other
problems remaining.

> That particular problem only applies if running code within the
> container as root.  How about if running code as an unprivileged user?
> With that addition, does systemd-nspawn provide a secure container
> (modulo local privilege escalation vulnerabilities)?

You cannot boot a full system without handing out root access to a
container. But one of the advantages of nspawn is actually that it
allows you to boot a full OS inside it just like that.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.