[systemd-devel] [PATCH] SELINUX: add /sys/fs/selinux mount point to put selinuxfs
Eric Paris
eparis at parisplace.org
Wed May 11 13:40:33 PDT 2011
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....
-Eric
More information about the systemd-devel
mailing list