Re: [PATCH] securityfs

Stephen Smalley
2005-07-06T16:50:42Z

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