On Wed, 2005-07-06 at 02:52 -0400, James Morris wrote: > On Sun, 3 Jul 2005, Greg KH wrote: > > > Good idea. Here's a patch to do just that (compile tested only...) > > > > Comments? > > Looks promising so far. > > I'm currently porting selinuxfs funtionality to securityfs, although I'm > not sure if we'll be ok during early initialization. selinuxfs is > currently kern_mounted via an initcall. We may need an initcall > kern_mount() of securityfs before SELinux kicks in. > > Stephen: opinions on this?
The reason for creating a kernel mount of selinuxfs at that point is so that the selinuxfs_mount vfsmount and selinux_null dentry are available for flush_unauthorized_files to use. > Otherwise, it looks like it'll allow SELinux to drop some code. Generally > it will mean that other LSM components won't have to create their own > filesystems, and their subdirectories will be hanging off /security (or > wherever selinuxfs is mounted), rather than scattered across / > > Some of the SELinux code may be useful as part of securityfs later, as > well. We need to be able to assign specific security labels to specific inodes in selinuxfs, particularly for the booleans, but ideally for any of them. Userspace compatibility is obviously a concern for such a change. libselinux determines where selinuxfs is mounted during library initialization by checking /proc/mounts for selinuxfs, and rc.sysinit does likewise. /sbin/init performs the initial mount of selinuxfs prior to initial policy load. Further, the existence of selinuxfs in /proc/filesystems is used as a test of whether SELinux was enabled in the kernel (e.g. is_selinux_enabled in libselinux). I'm not sure such a change is worthwhile for SELinux; large amount of disruption for little real gain. -- 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/
