Re: [PATCH v9 1/2] LSM: Multiple concurrent LSMs

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

On 12/6/2012 9:11 AM, Kees Cook wrote:
> On Thu, Dec 6, 2012 at 8:58 AM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 12/06/2012 05:49 AM, Tetsuo Handa wrote:
>>> John Johansen wrote:
>>>> This is not
>>>> something I want to do but if that is what is necessary to get stacking done
>>>> I will do it.
>>> Sharing existing interfaces by managing the format is a thorny path.
>>> Future LSM modules, if they are to use existing interfaces, might want to allow
>>> attributes up to 4000 bytes when overall length is limited to 4096 bytes.
>>>
>>>> Of course modifying apparmor doesn't take care of other LSMs so either certain
>>>> restrictions have to be part of the api for this interface or as Tetsuo suggests
>>>> a new interface would be needed.
>>> TOMOYO uses /sys/kernel/security/tomoyo/self_domain (handled by stateless
>>> tomoyo_read_self()/tomoyo_write_self()) for reading/updating current thread's
>>> attribute and /sys/kernel/security/tomoyo/.process_status (handled by
>>> stateful tomoyo_write_pid()/tomoyo_read_pid()) for reading arbitrary thread's
>>> attribute. I think that most programs will, if need to access attribute
>>> information, need to access only current thread's attribute. Therefore,
>>> /sys/kernel/security/tomoyo/self_domain handles only current thread and
>>> /sys/kernel/security/tomoyo/.process_status handles arbitrary threads.
>>>
>>> If AppArmor can migrate from existing /proc/pid/attr/ to its own interfaces
>>> like TOMOYO does, we can immediately get LSM stacking with "optionally either
>>> SELinux or SMACK" + "optionally AppArmor" + "optionally TOMOYO" + "optionally
>>> Yama" + "optionally other LSM modules". SELinux and SMACK are forever exclusive
>>> due to conflicts on other hooks.
>>>
>> So moving apparmor to use its own interface for setting values is reasonable,
>> though being able to fall back to /proc/<pid>/attr/* for none stacking cases
>> to support older userspace releases would be good.
>>
>> However getprocattr is a little more problematic as leveraging standard tools
>> that have been modified to support the security context (eg. ps -Z, etc) has
>> been standard practice, and is used a lot more than writing to /proc/<pid>/attr/*
>> Moving to our own interface looses this standard tool support.
>>
>> There are possible solutions, like multiplexing reading of /proc/<pid>/attr/*,
>> but not writes (yes I know its still problematic).
> Does it make sense to make attr read-only and leave its output
> multiplexed so "ps -Z" output is human readable?

This may work long term, but would break backward compatibility.

> Regardless, how about we just give attr to the "primary"

I much prefer referring to this as the "presented" LSM than
as the "primary". All LSMs are equal, one just gets to talk louder.

> LSM for now,

The disadvantage is that ps -Z, which simply reads /proc/pid/attr/current
has to get smarter all of a sudden.

> just to land this patch series? It's already a big patch, and I think
> it would be beneficial to get the bulk of the stacking logic in. We
> can improve the attr handling going forward, since that doesn't seem
> to affect the _structure_ of the changes.

For my next trick I'll try using the CONFIG_SECURITY_PRESENT value
if provided and the first LSM that includes a getprocattr hook otherwise.

Let me know if that sounds stupid.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.