[systemd-devel] nspawn remounts /selinux readonly, thus breaking logins

[Lennart Poettering]

On Fri, 08.07.11 08:21, Daniel J Walsh (dwalsh at redhat.com) wrote:

> >>>>>>> Newer versions of libselinux detect if /selinux is read-only and consider
> >>>>>>> selinux disabled if it is.
> >>>> But why is it disabled _outside_ of the container? This would mean that running
> >>>> nspawn disables selinux.
> >>
> >>> Hmm?
> >>
> >>> No, it's read-only only inside the container. We do that to make sure
> >>> the container cannot modify the selinux policy, since policies cannot be
> >>> virtualized really.
> > 
> > Nope, it becomes read-only outside. Some bug?
> > Repeating the commands from the original mail:
> > 
> > [zbyszek at fedora-15 ~]$ mount|grep selinux
> > selinuxfs on /selinux type selinuxfs (rw,relatime)      <----------------- RW here
> > [zbyszek at fedora-15 ~]$ sudo systemd-nspawn -D debian-tree/ /bin/true
> > Spawning namespace container on /home/zbyszek/debian-tree (console is /dev/pts/2).
> > [zbyszek at fedora-15 ~]$ mount|grep selinux
> > selinuxfs on /selinux type selinuxfs (ro,relatime)      <----------------- RO now
> > 
> >> I have no idea what nspawn does, but if you are turning the /selinux to
> >> readonly to prevent a root process from mucking with SELinux you are not
> >> going to be successful.  Since you can mount selinufs somewhere else and
> >> muck around with it. 
> > As I understand, absolute security is not on of the goals of nspawn. It is
> > only intended to prevent accidental breakage.
> > 
> >> If you want to run all of the processes within the
> >> nspawn environment under a single label, Like we do with Mock, then
> >> changing /selinux to read/only with the libselinux in Rawhide will give
> >> you want you want.  IE All processes within the container think SELinux
> >> is disabled, while SELinux is actually running all of the processes
> >> under confinement.
> > 
> > Zbyszek
> Lennart, I think to make this work correctly you need to bind mount
> /selinux on /selinux, then make the mount point private, then finally
> mount selinuxfs on /selinux read/only.  Otherwise since / is shared, the
> mounting within the namespace will show up on all namespaces.

What we currently do is mount a "fresh" selinuxfs into the container,
and not just a bind mount. Apparently that instance isn't so fresh after
all... So we probably should use explicit bind mounts after all, and
then make them read-only.

Most likely a similar problem exists with /proc and nspawn too, but is
not visible really.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.