On Wed, 2005-07-06 at 11:35 -0400, James Morris wrote: > When exactly is this needed? The securityfs mountpoint will be available > via a core_initcall, after which we can initialize the selinux subtree.
As long as it occurs prior to initial policy load, so that should be fine. > With securityfs, we'd have /sys/kernel/security/selinux configured during > kernel initialization. It still has to be mounted by userspace, right? So /sbin/init still needs to know to mount securityfs, and where the selinux nodes live under it, so you are still talking about changing it (and libselinux and rc.sysinit), and risking compatibility breakage for existing systems when they update their kernels. > Could be a simple change to look for the presence of > /sys/kernel/security/selinux Slightly different. That would correspond to checking for the presence of selinuxfs in /proc/mounts (i.e. has it been mounted), vs. the current check of selinuxfs in /proc/filesystems (i.e. has it been registered). The latter allows testing whether SELinux is enabled at all in the kernel, regardless of whether selinuxfs has been mounted in the process' namespace. In practice, the difference likely only matters for init and you can deal with distinction there. But again, this requires code change to libselinux, /sbin/init, and rc.sysinit at least, with coordinated update with the kernel. Certainly possible, but experience suggests it isn't likely to go smoothly. > I think it should reduce and simplify the SELinux kernel code, with less > filesystems in the kernel, consolidating several potential projects into > the same security filesystem. If there are several such projects in the first place... -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
