On Fri, 08.07.11 14:18, Zbigniew Jędrzejewski-Szmek ([email protected]) 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@fedora-15 ~]$ mount|grep selinux > selinuxfs on /selinux type selinuxfs (rw,relatime) <----------------- RW > here > [zbyszek@fedora-15 ~]$ sudo systemd-nspawn -D debian-tree/ /bin/true > Spawning namespace container on /home/zbyszek/debian-tree (console is > /dev/pts/2). > [zbyszek@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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
