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
