Re: [PATCH v14 3/6] LSM: Explicit individual LSM associations

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

On 8/1/2013 11:35 AM, Paul Moore wrote:
> On Wednesday, July 31, 2013 02:21:54 PM Casey Schaufler wrote:
>> On 7/31/2013 12:39 PM, Paul Moore wrote:
>>> On Wednesday, July 31, 2013 09:22:23 AM Casey Schaufler wrote:
>>>> On 7/30/2013 3:08 PM, Paul Moore wrote:
>>>>> On Thursday, July 25, 2013 11:32:11 AM Casey Schaufler wrote:
>>>>>> Subject: [PATCH v14 3/6] LSM: Explicit individual LSM associations
>>>>>>
>>>>>> Expand the /proc/.../attr interface set to help include
>>>>>> LSM specific entries as well as the traditional shared
>>>>>> "current", "prev" and "exec" entries. Each LSM that uses
>>>>>> one of the traditional interfaces gets it's own interface
>>>>>> prefixed with the LSM name for the ones it cares about.
>>>>>> Thus, we have "smack.current", "selinux.current" and
>>>>>> "apparmor.current" in addition to "current".
>>>>>>
>>>>>> Add two new interfaces under /sys/kernel/security.
>>>>>> The lsm interface displays the comma seperated list of
>>>>>> active LSMs. The present interface displays the name
>>>>>> of the LSM providing the traditional /proc/.../attr
>>>>>> interfaces. User space code should no longer have to
>>>>>> grub around in odd places to determine what LSM is
>>>>>> being used and thus what data is available to it.
>>>>>>
>>>>>> Introduce feature specific security operation vectors
>>>>>> for NetLabel, XFRM, secmark and presentation in the
>>>>>> traditional /proc/.../attr interfaces. This allows
>>>>>> proper handling of secids.
>>>>> Maybe I missed something, can you elaborate on this, perhaps even
>>>>> provide an example for us simple minded folk?
>>>> There are a set of facilities that (currently, at least)
>>>> can't be shared by multiple LSMs ...
>>> I should have been more specific.
>>>
>>> Thanks for the explanation, but that I understand the problems of stacking
>>> LSM/secids, we've had that conversation a few times now.  The explanation
>>> I was hoping for had to do with this sentence:
>>>
>>>  "Introduce feature specific security operation vectors for
>>>   NetLabel, XFRM, secmark and presentation in the traditional
>>>   /proc/.../attr interfaces."
>>>
>>> Can you explain this a bit more?  When I looked at the patch - and maybe
>>> I'm missing something - I didn't see anything in /proc that dealt with
>>> NetLabel, XFRM, and/or Secmark.
>> Just so. I have failed to communicate clearly.
>>
>>   "Each feature that requires support by a single, selected LSM
>>    is identified by a global pointer to that LSM's security_operations
>>    structure."
>>
>> NetLabel, XFRM and secmark are networking interfaces that can
>> send the security information from a single LSM along with the
>> packets of data.
>>
>> /proc/.../attr/current and SO_PEERSEC are interfaces that could
>> send information from multiple LSMs, but in most cases you have
>> to choose one LSM to placate your user space tools.
>>
>> In all of these cases it is necessary to identify the LSM to use.
>> Even though the end use is quite different the mechanism to support
>> the identification is the same.
> Okay, so if I understand everything correctly, there are no new entries in 
> /proc relating specifically to NetLabel, XFRM, or Secmark; although there are 
> new LSM specific entries for the general /proc entries that exist now.  Yes?

That's correct.

There is /sys/kernel/security/present, which tells you which LSM is going to
show up in /proc/.../attr/current.

Should we have /sys/kernel/security/XFRM, /sys/kernel/security/secmark,
/sys/kernel/security/NetLabel and /sys/kernel/security/SO_PEERCRED?