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

[Casey Schaufler]

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. :(

> 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