DBus Permissions

["Rahul Sandhu" <nvraxn@gmail.com>]

I've been looking into SELinux support for filtering DBus permissions
lately. Right now, we have a few things of note from the dbus class:

(class dbus (acquire_svc send_msg))

1. acquire_svc. This is useful for:
   Allowing contexts to own names on the bus. We have numerous names
   that exist on the bus that are effectively trusted: applications
   need to be able to trust that the owner of a name is the intended
   target. An example of this would be org.freedesktop.PolicyKit1 and
   polkit: applications check if unprivileged subjects are allowed to
   perform privileged operations using this DBus API. We can make use of
   acquire_svc to ensure that only e.g. polkit.subj may own that name.

2. send_msg. This is useful for ensuring that subjects may only speak
   to their intended targets.

However, this has some serious limitations. For one, many names on the
bus provide *both* unprivileged and privileged interfaces. An example
of this is org.freedesktop.systemd1, the systemd api. It has various
actions that aren't all that privileged (for example GetUnit) as well
as actions that are highly privileged (such as StartUnit). A bug has
been filed[1] such that any service capable of speaking to systemd over
dbus can effectively escape its sandboxing (systemd's sandboxing, not
selinux confinement)! It can simply start a transient unit using dbus
without the same restrictions applied to the unit.

In the case of systemd however, the situation is actually *much* better
than other cases: systemd is actually SELinux aware and is an object
manager, which means we at least have some control over what happens.
However, dbus is a pretty fundermental IPC primative for desktop Linux.
Plenty of things that aren't object managers nor SELinux aware provide
privileged and unprivileged interfaces on the same bus name. One of the
main advantages of brokering is the ability to perform various checks
without the server needing to implement them.

Hence, I propose extending what we can do with DBus to allow us to be
much more granular with it. Other LSMs and IPC systems already have
access control similar to this:

1. Android's binder supports service names being labelled[2]. This is
   slightly different to the case of DBus here with binder being part
   of the kernel, however the core concept could still apply as we may
   simply provide dropins to extend the functionality of dbus config
   to label names, and extend the dbus class. This would provide back-
   wards compatability. It's also somewhat limited however because of
   the DBus IPC design.

2. AppArmor has a much more rich access control setup for DBus. It does
   not require installing DBus policy files, and supports performing
   filtering based on the bus type, the path on the bus, the interface,
   and the member. It also supports representing this all in policy[3].
   This is in my opinion a much cleaner approach than requiring us to
   have loads of labels for each possible member and interface. However,
   I don't really have any idea as to how we this could represented in
   policy. Maybe something using xperms? But I'm a bit lost as to how
   an xperm set could be mapped to it.

[1] https://github.com/systemd/systemd/issues/8846
[2] https://source.android.com/docs/core/architecture/hidl/binder-ipc#names
[3] https://man.archlinux.org/man/apparmor.d.5.en#DBus_rules

Thoughts/suggestions?
Rahul