AppArmor mediation in dbus-daemon

[Simon McVittie]

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

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.

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 :-)

    S