Re: [PATCH] securityfs

[Stephen Smalley <sds@epoch.ncsc.mil>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/