[apparmor] Bug#800132: [pkg-apparmor] Bug#800132: libapparmor-dev: arch-dependent file in "Multi-Arch: same" package

[Simon McVittie]

On 28/09/15 09:11, intrigeri wrote:
>  Description: Document D-Bus getcon method in aa_getcon man page
...
> The blocker (AppArmor support in upstream D-Bus) is now gone, right?

I'm not Tyler, but I am a D-Bus maintainer. I think this patch should
*not* go upstream, because the method that it documents did not go
upstream into D-Bus. It should also be removed from Debian's apparmor
package, because it is misleading there (Debian's dbus package has never
had the documented method). Ubuntu's dbus package still has the
documented method, but only for backwards compat; so it would be OK for
this documentation to remain in Ubuntu's apparmor package, but it should
ideally be replaced by documentation of the upstream D-Bus API.

While incorporating AppArmor support into upstream D-Bus, Tyler and I
agreed that instead of GetConnectionAppArmorSecurityContext

    profile, mode = GetConnectionAppArmorSecurityContext(bus_name)

we should use the generic, LSM-agnostic GetConnectionCredentials method,
with this Python-like pseudocode:

    dictionary = GetConnectionCredentials(bus_name)
    array_of_bytes = dictionary.get("LinuxSecurityLabel")

and then parse that byte array locally using AppArmor functions. It's
the same thing you'd see in /proc/$PID/attr/current, with a trailing
'\0' always included in the stated length; it is represented as a
byte-array rather than a string because it isn't guaranteed that all
LSMs' security labels are valid UTF-8, and in D-Bus the string type is
defined to be Unicode encoded in UTF-8. It also works for non-AppArmor
LSMs (confirmed for SMACK).

GetConnectionCredentials also returns the uid and pid where available;
in practice, D-Bus services that are interested in processes' AppArmor
contexts are probably also interested in the uid and pid, so it's good
to get everything with one round-trip.

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