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
