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.
