AppArmor mediation in dbus-daemon

[Kay Sievers]

On Mon, Feb 17, 2014 at 9:13 PM, Tyler Hicks <tyhicks at canonical.com> wrote:
> Hi Lennart!
>
> On 2014-02-17 20:51:32, Lennart Poettering wrote:
>> On Mon, 17.02.14 13:34, Tyler Hicks (tyhicks at canonical.com) wrote:
>>
>> > I've created a bug, with patches, to add AppArmor mediation to
>> > dbus-daemon:
>> >
>> >   https://bugs.freedesktop.org/show_bug.cgi?id=75113
>> >
>> > The bug's description has the details, along with pointers to AppArmor
>> > docs describing the policy language.
>>
>> This goes ahead with that deep packet introspection logic I presume?
>
> It isn't deep packet introspection in dbus-daemon. The bus, path,
> interface, and member strings have been passed to the SELinux hooks for
> many years. SELinux didn't use them but AppArmor is using them.
>
>>
>> Note that something like this will never end up in kdbus, as discussed
>> previously. That of course doesn't mean this couldn't be added to
>> dbus-daemon right now, but I hope you understand that if you intend to
>> use kdbus one day, then adding support like this to good old dbus1
>> daemon is a dead-end already.
>
> I still think that it shouldn't be considered deep packet introspection
> in kdbus and plan on submitting some small patches to you guys (kdbus
> upstream) that move several fields to the kdbus message metadata.
>
> My intent isn't to be stubborn about the issue but I'd like to be sure
> that we're all on the same page about what I'm proposing. Patches are
> the only way to do that.

As pointed out already, with the current idea of split of kernel vs.
userspace, kdbus will not move them to the header. We are still
convinced that the kernel should not get involved in looking at or
passing these fields around. That leaves only other options for
AppArmor and kdbus, but not direct access in the primary kernel API.

Kay