Re: [PATCH] securityfs

[Stephen Smalley]

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