Re: [PATCH] Security/sysfs: Enable security xattrs to be set on sysfs files, directories, and symlinks.

[Casey Schaufler <casey@schaufler-ca.com>]

David P. Quigley wrote:
> On Thu, 2009-07-09 at 10:50 -0700, Greg KH wrote:
>   
>> On Thu, Jul 09, 2009 at 01:26:44PM -0400, David P. Quigley wrote:
>>     
>>> I just read over Casey's comments again and I'm pretty sure we have a
>>> big misunderstanding here. From his initial response it seems that he
>>> thinks that I am exposing the secids to userspace as the way for setting
>>> the labels on files. That isn't true. We are still using the full string
>>> based labels for the userspace interface what the secid is used for is
>>> to allow the kernel to keep track of changes until the sysfs_dirent is
>>> destroyed. 
>>>       
>> Ok, if Casey and others agree that this is the best solution, I'll take
>> it.
>>
>> thanks,
>>
>> greg k-h
>>     
>
>
> I haven't heard from Casey since his last email so I'd hold off on
> taking this until we come to an agreement.

Yeah. Pardon the day job.

>  It seems though from your
> comments in another mail that putting the persistent data into the
> sysfs_dirent is the proper approach and we just need to figure out what
> to put there.
>   

Now that I've really had a chance to review the patches carefully
my worst fears have been put to rest. I don't doubt that what you've
got will work any longer. I do object to using a secid, but I've had
to give in on that before.

If your secid is valid at any given time you have a context (which
is a text string) available at the same time that you can point to.
If this were not true a call to security_xattr_to_secid() could
not be counted on to succeed. You could define
security_xattr_to_secctx() and have it return the Smack value for
Smack and the context for SELinux instead of security_xattr_to_secid().
Sure, you've got a string to maintain, but it had better not be going
away in SELinux, because if it does the secid is going with it. Unless
I recall incorrectly (always a possibility) it has been some time
since the avc could really be considered a cache. I am willing to
bet beers that you could safely point to a mapping somewhere and
not worry much about it.

If not, you've got other performance issues in SELinux.