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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

    smcv



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux