On Fri, 08.07.11 07:59, Daniel J Walsh ([email protected]) wrote: > > 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. > > > > Lennart > > > 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.
nspawn is not a security solution really. We try to make that very clear in the man pages: Linux containers are not suitable for completely secure isolation from the host system, there are still a lot of holes. What nspawn does is try to make sure that *accidental* changes to the host system fail. I.e. we want to make sure that you can install the usual distributions in a container, and the boot scripts of those do not end up loading a different selinux policy into the host kernel. In fact, there are many ways how nspawn containers (and LXC for the matter) can interfere with the host system. Besides /selinux we mount /sys and /proc/sys into the container read-only. People can just remount that rw with "mount /sys -orw,remount" and have access. It's that simple. > 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. Yes, this is what we want. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
