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

[Lennart Poettering]

On Fri, 08.07.11 14:18, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> >>>>>>> In case of a login on a tty, the question about a security context
> >>>>>>> is displayed on the screen. In case of ssh login, if just fails
> >>>>>>> without any message displayed on the remote side.
> >>>>>>
> >>>>>> 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

Oh, hmm, this looks like a bug, indeed. Weird. The read-only-ness should not be
propagated to the host system.

> > 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.

Correct.
> 
Lennart

-- 
Lennart Poettering - Red Hat, Inc.