[PATCH v12 23/25] NET: Add SO_PEERCONTEXT for multiple LSMs
smcv at collabora.com
Thu Dec 19 12:19:39 UTC 2019
On Wed, 18 Dec 2019 at 15:50:45 -0500, Stephen Smalley wrote:
> Ok, this seems to be a lack of support in AppArmor for saving the peer info
> for unix/local domain sockets, so not your bug. Doesn't implement the
> necessary hooks.
Ubuntu kernels have working getsockopt SO_PEERSEC for AppArmor (which
definitely works for D-Bus, or did when I tried it in the past), but it
seems to be a downstream patch.
Is there a combination of LSMs where this works correctly and shows
multiple LSMs' labels, either upstream or with downstream patches? D-Bus
ought to be an early consumer of this information, but that's going to
be difficult if there's nowhere I can test it. If there was a pair of
in-tree or out-of-tree test LSMs that automatically labelled process
12345 and all sockets that it created with something like (pseudocode)
then that would make testing straightforward.
>From my user-space developer perspective, I'd really like the kernel
to have at least brief documentation of the assumptions that can be
made about the compound format, to avoid people like me having to
ask the linux-security-module mailing list and use the answers as our
- Can I assume that the LSM names (conceptually, keys in the associative
array) are printable ASCII? If not, can I at least assume that they are
printable UTF-8, or that LSMs whose names are not printable UTF-8 are
too weird to be worth supporting in user-space APIs?
If this decision hasn't been made yet, I would like to request ASCII,
or UTF-8 if a wider character repertoire is desired - that would make
user-space APIs a lot easier to write.
- What can I assume about the format of the labels (values in the
From previous conversations on linux-security-module it seems the
answer is: they are intended to be printable strings; their encoding
is unspecified (could be ASCII or UTF-8, but equally could be Latin-1
or anything else); there are no reserved or disallowed characters
except '\0'; individual LSMs like SELinux and AppArmor might impose
tighter restrictions, but LSM-agnostic code can't assume those
restrictions are present.
Even if the format is conceptually an unspecified encoding with every
nonzero byte allowed, if LSM and security policy authors establish a
convention that the labels are ASCII or UTF-8 without control characters
such as newlines, that would make user-space a lot easier to deal with.
- Can I assume that the names and labels in /proc/$pid/attr/context
correspond exactly (same label <=> same bytes) to the ones in
In particular, a design issue in the previous interfaces with
/proc/$pid/attr/current and SO_PEERSEC was that AppArmor puts
"unconfined\n" in /proc/$pid/attr/current, but "unconfined\0" in
SO_PEERSEC, and implementations of protocols like D-Bus can't know
that these are meant to be the same without LSM-specific knowledge
(namely "AppArmor profile names can't contain newlines").
If this new API is an opportunity to declare that LSMs are expected
to put the same canonical form of a label in /proc/$pid/attr/context and
SO_PEERCONTEXT, possibly with a non-canonical version (adding '\n' or
'\0' or similar) exposed in the older /proc/$pid/attr/current and
SO_PEERSEC interfaces for backwards compatibility, then that would make
life a lot easier for user-space developers like me.
- Does the order of the names and values matter? Can I assume anything
It would make the D-Bus API more straightforward if I can assume that
the order doesn't matter, and represent it as an unordered map
(associative array), like a Perl hash or Python dict.
I'm asking all this from the D-Bus perspective, but anything that
wants to store or forward LSM contexts in an LSM-agnostic way will
have essentially the same requirements - I could imagine X11, Wayland,
varlink etc. hitting the same problems D-Bus did.
More information about the Linux-security-module-archive