On Fri, 08.07.11 08:21, Daniel J Walsh ([email protected]) 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@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 > > > >> 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
