AppArmor mediation in dbus-daemon

Lennart Poettering mzqohf at 0pointer.de
Tue Feb 18 01:38:39 CET 2014


On Mon, 17.02.14 17:29, Marc Deslauriers (marc.deslauriers at canonical.com) wrote:

> > Meanwhile, the pragmatic objection is that the traditional XML
> > security-policy language in dbus-daemon can be charitably described as
> > "non-obvious". People filtering by path, interface and method name
> > have traditionally forgotten to allow the Peer, Introspectable and/or
> > Properties interfaces, for instance. I'm sure there are errors in the
> > opposite direction (accidentally allowing things that should not have
> > been allowed) as well. "Either you can receive messages from me, or
> > you can't" has the advantage of being simple enough for non-specialist
> > developers to understand :-)
> 
> Well, being hard to understand doesn't make something any less valuable. The big
> issue with the traditional XML security files was that they weren't dynamic, and
> couldn't be different based on a particular process. Although they did allow a
> sysadmin to customize their installation, I would agree that they were quite
> limited and rarely got modified. Modifying destinations to enforce the simple
> security rules of the traditional XML files makes sense, but what we are
> achieving with LSM integration in dbus-daemon currently is much more
> than that.

You can believe mew: I really dislike the XML policy language, but
there's one thing I think is good about it: that it doesn't try to be
"dynamic" (well, modulo the at_console stuff, wich is kinda a
failure). If you want dynamic policy this really should be done by
something like PK that can do all that with all appropriate hook-ups and
activity... But trying to cram dynamic access control into a static
policy is just failure...

> I suggest we wait and see what Tyler's patches look like just so we're all on
> the same page in regards to what modifications to kdbus this type of integration
> would involve. If ultimately they get NACKed, so be it, but we'll at least know
> how intrusive the changes were before making a judgement.

Well, you know, this issue we are having here is quite
fundamental. Patches are not a particularly convincing ways to change
fundamental oppostion to an approach...

Sorry, but this will not work, try to rethink your concept, otherwise
you are just doing work for the bin...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the dbus mailing list