AppArmor mediation in dbus-daemon

[Marc Deslauriers]

On 14-02-17 03:49 PM, Simon McVittie wrote:
> On 17/02/14 20:13, Tyler Hicks wrote:
>> 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.
> 
> I think the conceptual objection here is that the path, interface and
> member name are not used for routing in the dbus-daemon (or kdbus) at
> all: message routing depends entirely on the bus (session vs. system)
> and the destination bus name.
> 
> Everything "smaller than" the destination bus name is interpreted by
> the destination, which does further internal routing, usually in C
> code. If you don't trust the destination, then why should you trust it
> to route messages correctly? Or, conversely, if you don't trust the
> sender, why can't you trust the destination to recognise it as
> unprivileged and say "no"?
> 


I understand the conceptual objection, but there is a great opportunity here in
being able to move the path, interface and member names into something that can
be directly enforced by the policy that confines an application.

Destinations aren't necessarily malicious, they simply may not have been
designed in a way that would allow the fine-grained security policy necessary
for certain security models, such as having a more restricted set of methods for
certain untrusted applications. Ideally, all destinations accessible from an
untrusted application would be enforce proper security. But realistically, we're
running hundreds of components that will each have their own way of determining
what the appropriate policy should be. Having a central location to do this that
can be audited just makes more sense from a security point of view.

Security isn't an all-or-nothing proposition, often it is simply about reducing
scope of what is exposed to untrusted applications. For example, seccomp is used
not only to prevent an application from accessing unwanted API, but also as a
way of reducing the scope of potential vulnerabilities that are exposed by the
APIs the application doesn't require.

Even if all destinations were to enforce security, having a single point of
access control that can be audited and logged so the message doesn't even get to
the destination in the first place is valuable.

> To use the standard "if D-Bus services were web servers" analogy:
> well-known bus names are DNS names, unique bus names are IP addresses,
> the path, interface and member name are header fields in the HTTP
> request, and dbus-daemon/kdbus is a network router or a proxy server
> or something.

The analogy is quite fitting. Some people want dbus-daemon/kdbus to be a dumb
network router, but I want it to be a proxy server in this scenario that will
allow me to set security filters based on certain criteria.

One thing I don't want is for kdbus to parse the payload. I simply would like
the path, interface and member names to be removed from the payload and become
part of the metadata so it can be filtered and logged.

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

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.

Marc.