AppArmor mediation in dbus-daemon

[Tyler Hicks]

On 2014-03-13 14:32:41, Alban Crequy wrote:
> 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,

Hi Alban!

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

Correct

> 
> 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?

Also 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.

Right. We lose the ability to do fine grained filtering on the message
metadata and can only do the traditional connection-based enforcement.

Tyler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20140313/0c9b85cc/attachment.pgp>