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

[Stephen Smalley]

On 1/6/20 12:29 PM, 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 don't
>> understand why AA continues to keep this kind of basic and longstanding
>> downstream functionality out of tree.
> 
> 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).
> 
> 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.

AA+SELinux with these patches boots fine for me with Fedora; it doesn't 
load any policy for AA but you still get a compound context from 
/proc/pid/attr/context.  Should be similar for booting with a distro 
that only enables AA by default; you'll get "kernel" for the SELinux 
part of the compound label in the absence of any policy loaded.