[PATCH v13 23/25] NET: Add SO_PEERCONTEXT for multiple LSMs

[Stephen Smalley]

On 1/6/20 1:03 PM, Casey Schaufler wrote:
> On 1/6/2020 9:29 AM, Simon McVittie wrote:
>> On Mon, 06 Jan 2020 at 12:15:57 -0500, Stephen Smalley wrote:
>>> On 12/24/19 6:59 PM, Casey Schaufler wrote:
>>>> The getsockopt SO_PEERSEC provides the LSM based security
>>>> information for a single module, but for reasons of backward
>>>> compatibility cannot include the information for multiple
>>>> modules. A new option SO_PEERCONTEXT is added to report the
>>>> security "context" of multiple modules using a "compound" format
>>>>
>>>>           lsm1\0value\0lsm2\0value\0
>>>>
>>>> This is expected to be used by system services, including dbus-daemon.
>>>> The exact format of a compound context has been the subject of
>>>> considerable debate. This format was suggested by Simon McVittie,
>>>> a dbus maintainer with a significant stake in the format being
>>>> usable.
>>> Since upstream AA does not currently ever set the peer label info, there is
>>> no need for this support for stacking upstream AA today, and there is no way
>>> to test this functionality with more than one module present currently in an
>>> upstream kernel.  Either fix AA to actually implement the functionality so
>>> it can be tested properly, or drop it from this series please.
> 
> I agree that SO_PEERCONTEXT can be deferred until such time as we have
> AppArmor upstream support for SO_PEERSEC.
> 
>>>    I don't
>>> understand why AA continues to keep this kind of basic and longstanding
>>> downstream functionality out of tree.
> 
> Not everyone has the resource commitments of the world's largest
> government. :(

How hard is it to upstream code that is a) entirely contained within the 
AA security module, and b) already shipping in Ubuntu kernels for quite 
some time? Seems to be more of a lack of an upstream-first philosophy 
than a resources issue...

> 
>> Alternatively, a pair of tiny in-tree or out-of-tree stackable LSMs
>> that don't make any security decisions, and label every labellable
>> process/socket/thing with something predictable, would make it really
>> easy for both kernel and user-space developers to test this and the
>> user-space code that uses it (D-Bus and others).
> 
> Sounds like a fun and educational project. Maybe one of our lurkers
> could do something clever.
> 
>>
>> For example, they could label process 1234 and all sockets created by
>> process 1234 with "contexttest1\0pid1234\0contexttest2\0process1234" or
>> something like that.
>>
>> I'd love to see AppArmor in upstream kernels support SO_PEERSEC and
>> SO_PEERCONTEXT, but setting up a development machine to stack AppArmor
>> and SELinux (and still be able to boot, without one or the other LSM
>> forbidding something important) seems likely to be harder than setting
>> it up to load some toy LSMs.
> 
>>
>>      smcv
>