AppArmor mediation in dbus-daemon

[Alban Crequy]

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.

Hi,

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
message metadata.

I picked the following rule from
https://lists.ubuntu.com/archives/apparmor/2013-November/004686.html

  /usr/bin/pulseaudio {
    dbus (send)
      bus="system"
      path="/org/bluez/*/hci[0-9]"
      interface="org.bluez.Media"
      member="RegisterEndpoint"
      peer=(name="org.bluez"),
  }

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:

  /usr/bin/pulseaudio {
    dbus (send)
      bus="system"
      peer=(name="org.bluez"),
  }

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.

Alban