[apparmor] LSMs' contexts/labels: can user-space APIs generalize?

[Simon McVittie]

I'm trying to get AppArmor and other LSMs' integration with D-Bus 
upstreamed into dbus.git. I recently posted the message below to the 
linux-security-module list and got some feedback from SELinux and Smack 
developers, and am now re-posting here in the hope of getting AppArmor 
opinions; full text of the beginning of the thread below. See 
<http://marc.info/?l=linux-security-module&m=142315527731162&w=2> for 
the full thread.

Follow-ups to linux-security-module preferred, but if people aren't on 
that list, please reply here and I'll summarize over there.

On 05/02/15 16:54, Simon McVittie wrote:
> At the moment, D-Bus has SELinux integration: it can retrieve a SELinux
> context from the peer of a connection and pass that information through
> the dbus-daemon. I've been asked to review two branches for Smack and
> AppArmor integration, which among other things, do the same thing with
> Smack labels and AppArmor contexts. This seems slightly redundant.
>
> Retrieving any of these security labels seems to boil down to a call to
>
>      getsockopt (fd, SOL_SOCKET, SO_PEERSEC, buf, &size)
>
> with a retry loop for an increasingly large buffer, and sometimes some
> postprocessing (selinux_raw_to_trans_context() for SELinux). At the
> moment, libdbus is optionally linked to libselinux to do that, and the
> proposed branches add optional linking to libapparmor and libsmack.
>
> Instead of having separate get_selinux_context(), get_apparmor_context()
> and get_smack_label() APIs, would it be reasonable for an LSM-agnostic
> user-space library like libdbus to expose the SO_PEERSEC byte-array to
> its users via some API like get_linux_security_label(), and expect those
> that care about LSMs to parse it appropriately, including passing it
> through any post-processing that the specific LSM wants?
>
> If that would be a reasonable approach, is there anything I can safely
> assume about the label/context, beyond "it is an array of bytes of some
> arbitrary length known to the kernel"? D-Bus can carry arbitrary
> byte-arrays, but they lead to less convenient library APIs than those
> that would be possible if we know that the contexts are in fact always
> \0-terminated UTF-8 strings or \0-terminated bytestrings - so the more
> guarantees about contents there are, the more convenient I can make it
> to use this stuff.
>
> Here are the sort of questions I would need to ask:
>
> * what is it canonically called when referring to it outside the
>    context of specific LSMs? ("security label"?)
>
> * is it always "basically a string" regardless of LSM, or would a
>    future LSM be free to use binary blobs for its labels?
>
> * is it guaranteed to come out of the kernel with a terminating \0
>    already included in the length, or with no terminating \0,
>    or could it go either way? Can a user-space library assume that
>    appending \0 does not lose information?
>
> * is it guaranteed to be UTF-8 or ASCII, or can it have arbitrary bytes
>    with the high bit set, in any or no encoding, like filenames can?
>
> * is it guaranteed not to contain embedded \0? (the answer to this one
>    appears to be "no" because AppArmor uses "context\0mode\0")

(I'm now aware that this was a misunderstanding; see 
http://marc.info/?l=linux-security-module&m=142323210620028&w=2 for 
corrected version)

> * if LSMs are stacked, can user-space determine whose version of the
>    context it has received from SO_PEERSEC? (if this situation is even
>    possible)
>
> * for the specific cases of SELinux, Smack and AppArmor,
>    - what is the right jargon term? (as far as I can tell it's a SELinux
>      *context*, a Smack *label*, or an AppArmor *context* consisting of
>      one or more *profiles*)
>    - what would some typical real-world values look like?
>      (I want to be able to give illustrative examples in the D-Bus
>      specification, which is currently really vague on the subject)
>    - do any additional LSM-specific guarantees hold?
>
> I realise that it's entirely possible that none of the guarantees I'm
> hoping for exist, and I might still have to add a parallel API for each
> LSM; but I'm asking first, on the off-chance that I can make this easier
> to use and less prone to duplication.
>
> If you are interested in D-Bus' interactions with LSMs, please consider
> adding yourself to the Cc on
> https://bugs.freedesktop.org/show_bug.cgi?id=75113 (AppArmor),
> https://bugs.freedesktop.org/show_bug.cgi?id=47581 (Smack) and/or
> https://bugs.freedesktop.org/show_bug.cgi?id=84193 (SELinux).
>
> Thanks,
>      S
>

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>