[systemd-devel] [PATCH] SELINUX: add /sys/fs/selinux mount point to put selinuxfs
Casey Schaufler
casey at schaufler-ca.com
Wed May 11 10:10:08 PDT 2011
On 5/11/2011 7:43 AM, Greg KH wrote:
> On Wed, May 11, 2011 at 04:27:59PM +0200, Kay Sievers wrote:
>> On Wed, May 11, 2011 at 15:54, Greg KH <greg at kroah.com> wrote:
>>> On Wed, May 11, 2011 at 01:22:42PM +0200, John Johansen wrote:
>>>> On 05/11/2011 03:59 AM, Greg KH wrote:
>>>>> On Tue, May 10, 2011 at 03:55:24PM -0700, Casey Schaufler wrote:
>>>>>> On 5/10/2011 3:34 PM, Greg KH wrote:
>>>>>>> From: Greg Kroah-Hartman <gregkh at suse.de>
>>>>>>>
>>>>>>> In the interest of keeping userspace from having to create new root
>>>>>>> filesystems all the time, let's follow the lead of the other in-kernel
>>>>>>> filesystems and provide a proper mount point for it in sysfs.
>>>>>>>
>>>>>>> For selinuxfs, this mount point should be in /sys/fs/selinux/
>>>>>> It seems that we might want this to be an LSM interface standard.
>>>>>> Is the call to kobject_create_and_add and associated cleanup all
>>>>>> that's required? I would want Smack to follow the convention as
>>>>>> well.
>>>>> You could always just create a subdir under /sys/security/ if you have
>>>>> your own filesystem, but I don't think that Smack has one, right?
>>>>>
>>>>> Is it going to get one? If so, we might want to revisit the idea of
>>>>> securityfs if no one is actually using it...
>>>>>
>>>> resending, as this looks to have been lost
>>>>
>>>> AppArmor, IMA, and TOMOYO are using securityfs currently.
>>> Great, then it will not go anywhere.
>> Just to get an idea how all this fits together. How can TPM bios and
>> IMA/AppArmor share this directory? They have their own subdirs in
>> there, or both just use the securityfs infrastructure and not their
>> own filesystem on top?
> Only one security module is allowed to be loaded/active at any one point
> in time, so they can't step on each other.
This is true today, but I seriously think we're going to break down
this barrier before long. I see this as a significant reason to sort
the location of LSM control filesystems.
More information about the systemd-devel
mailing list