AppArmor mediation in dbus-daemon
alban.crequy at collabora.co.uk
Thu Mar 13 07:32:41 PDT 2014
On Mon, 17 Feb 2014 20:51:32 +0100
Lennart Poettering <mzqohf at 0pointer.de> 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?
> 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 would like to make sure I understand what AppArmor could do with
kdbus and what is not possible to do without moving new fields in kdbus
I picked the following rule from
This rule would not be enforceable with a kdbus+AppArmor system because
there will be no way to read the path, interface and member from the
kdbus message metadata.
However, enforcing this rule:
would be implementable because kdbus understands well-known names.
Is it correct?
So a AppArmor+kdbus system would be less useful than
AppArmor+dbus-daemon but it can still be useful to prevent (let's say)
telepathy-gabble to talk to org.bluez.
More information about the dbus