This article is written by Sven Vermeulen, the author of SELinux Cookbook. In this article, we will cover how to control D-Bus message flows.

(For more resources related to this topic, see here.)

Controlling D-Bus message flows

D-Bus implementation on Linux is an example of an SELinux-aware application, acting as a user space object manager. Applications can register themselves on a bus and can send messages between applications through D-Bus. These messages can be controlled through the SELinux policy as well.

Getting ready

Before looking at the SELinux access controls related to message flows, it is important to focus on a D-Bus service and see how its authentication is done (and how messages are relayed in D-Bus) as this is reflected in the SELinux integration.

Go to /etc/dbus-1/system.d/ (which hosts the configuration files for D-Bus services) and take a look at a configuration file. For instance, the service configuration file for dnsmasq looks like the following:

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus 
 Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<policy user="root">
   <allow own="uk.org.thekelleys.dnsmasq"/>
   <allow send_destination="uk.org.thekelleys.dnsmasq"/>
</policy>
<policy context="default">
   <deny own="uk.org.thekelleys.dnsmasq"/>
   <deny send_destination="uk.org.thekelleys.dnsmasq"/>
</policy>
</busconfig>

This configuration tells D-Bus that only the root Linux user is allowed to have a service own the uk.org.thekelleys.dnsmasq service and send messages to this service. Others (as managed through the default policy) are denied these operations.

On a system with SELinux enabled, having root as the finest granularity doesn't cut it. So, let's look at how the SELinux policy can offer a fine-grained access control in D-Bus.

How to do it…

To control D-Bus message flows with SELinux, perform the following steps:

Identify the domain of the application that will (or does) own the D-Bus service we are interested in. For the dnsmasq application, this would be dnsmasq_t:
```
~# ps -eZ | grep dnsmasq | awk '{print $1}'
system_u:system_r:dnsmasq_t:s0-s0:c0.c1023
```

Identify the domain of the application that wants to send messages to the service. For instance, this could be the sysadm_t user domain.

Allow the two domains to interact with each other through D-Bus messages as follows:

gen_require(`
class dbus send_msg;
')
allow sysadm_t dnsmasq_t:dbus send_msg;
allow dnsmasq_t sysadm_t:dbus send_msg;

How it works…

When an application connects to D-Bus, the SELinux label of its connection is used as the label to check when sending messages. As there is no transition for such connections, the label of the connection is the context of the process itself (the domain); hence, the selection of dnsmasq_t in the example.

When D-Bus receives a request to send a message to a service, D-Bus will check the SELinux policy for the send_msg permission. It does so by passing on the information about the session (source and target context and the permission that is requested) to the SELinux subsystem, which computes whether access should be allowed or not. The access control itself, however, is not enforced by SELinux (it only gives feedback), but by D-Bus itself as governing the message flows is solely D-Bus' responsibility.

This is also why, when developing D-Bus-related policies, both the class and permission need to be explicitly mentioned in the policy module. Without this, the development environment might error out, claiming that dbus is not a valid class.

D-Bus checks the context of the client that is sending a message as well as the context of the connection of the service (which are both domain labels) and see if there is a send_msg permission allowed. As most communication is two-fold (sending a message and then receiving a reply), the permission is checked in both directions. After all, sending a reply is just sending a message (policy-wise) in the reverse direction.

It is possible to verify this behavior with dbus-send if the rule is on a user domain. For instance, to look at the objects provided by the service, the D-Bus introspection can be invoked against the service:

~# dbus-send --system --dest=uk.org.thekelleys.dnsmasq --print-reply 
 /uk/org/thekelleys/dnsmasq 
 org.freedesktop.DBus.Introspectable.Introspect

When SELinux does not have the proper send_msg allow rules in place, the following error will be logged by D-Bus in its service logs (but no AVC denial will show up as it isn't the SELinux subsystem that denies the access):

Error org.freedesktop.DBus.Error.AccessDenied: An SELinux policy 
 prevents this sender from sending this message to this recipient. 0 
 matched rules; type="method_call", sender=":1.17" (uid=0 pid=6738 
 comm="") interface="org.freedesktop.DBus.Introspectable" 
 member="Introspect" error name="(unset)" requested_reply="0" 
 destination="uk.org.thekelleys.dnsmasq" (uid=0 pid=6635 comm="")

When the policy does allow the send_msg permission, the introspection returns an XML output showing the provided methods and interfaces for this service.

There's more...

The current D-Bus implementation is a pure user space implementation. Because more applications become dependent on D-Bus, work is being done to create a kernel-based D-Bus implementation called kdbus. The exact implementation details of this project are not finished yet, so it is unknown whether the SELinux access controls that are currently applicable to D-Bus will still be valid on kdbus.

Summary

In this article, we learned how to control D-Bus message flows. It also covers what happens when the policy has or doesn't have the send_msg permission in place.