[systemd-devel] [PATCH] SELINUX: add /sys/fs/selinux mount point to put selinuxfs

[Casey Schaufler]

On 5/11/2011 1:40 PM, Eric Paris wrote:
> On Wed, May 11, 2011 at 4:22 PM, Greg KH <greg at kroah.com> wrote:
>> On Wed, May 11, 2011 at 04:14:32PM -0400, Eric Paris wrote:
>>> On Wed, May 11, 2011 at 3:56 PM, Greg KH <greg at kroah.com> wrote:
>>>> On Wed, May 11, 2011 at 10:14:40AM -0700, Casey Schaufler wrote:
>>>>> I would prefer /sys/security for all LSMs, but if SELinux goes with /sys/fs
>>>>> Smack will likely follow on the theory that mirroring the current dominant
>>>>> LSM is more likely to please the masses than doing what the greatest number
>>>>> of LSMs are doing.
>>>> Is smack going to create its own filesystem like selinux has, or is it
>>>> going to use securityfs?  If securityfs, then stick with what you have.
>>>> If you are going to create a new one, I'd be glad to work with you to
>>>> add anything you might need to securityfs first, but if that doesn't
>>>> work out, then yes, you could use /sys/fs/ for your new one.
>>> Pretty sure we already have a securty/smack/smackfs.c .....
>> Doh, you are right.  Ok, I'll just shutup now then...
>>
>> greg k-h
> I'm willing to put in a day or two trying to move selinux to
> securityfs, but there is one thing I'm not sure how to handle, mainly
> when it comes to userspace backwards compat.  Greg, maybe you can give
> me ideas.
>
> My biggest issue is how libselinux historically found selinuxfs.
> Given that people will likely use this library forever even with new
> kernels (*cough* akpm *cough*) I sorta feel like we need to continue
> to support it.  The libselinux library had 3 tests.
>
> 1) check statfs(2) on /selinux and if it was selinuxfs magic we are done
> 2) check /proc/filesystems to see if selinuxfs exists, if not, selinux
> is disabled
> 3) check /proc/mounts and find if/where selinuxfs is mounted
>
> If we just move the selinuxfs mount around the filesystem it's no big
> deal.  The old library will find it.  It would be new userspace that
> mounted it in a new place, so that new userspace could make the check
> in (1) look at the new place.  If we actually replace selinuxfs with
> securityfs step 2 is going to fail.  I can probably fake it somehow
> and pretend that selinuxfs exists as an fs, but I don't really know
> how to fake /proc/mounts so even though /sys/kernel/security/* is
> actually securityfs /sys/kernel/security/selinux looks like selinuxfs
> in /proc/mounts.
>
> I guess maybe the way to do it is to make selinuxfs as it stands today
> a config option.  I don't see a reason we couldn't implement a whole
> new set of selinux inodes in securityfs along with those in selinuxfs.
>  Old userspace would mount selinuxfs on /selinux and would need the
> compat kernel option while new userspace would change it's tests to
> be:
>
> 1) check for /sys/kernel/security/selinux/"something"
> 2) check for securityfs and if not assume disabled
> 3) check /proc/mounts and find securityfs, then check for "something"
>
> I'd rather not have two complete implementations of selinuxfs but if
> it gets us to a good endgame I guess I'm willing to support it....
>

Isn't it about time we had /sys/kernel/lsm, which would contain the name
of the active LSM?