Security/Smack setting of DBUS
This page describes how to configure DBUS for SMACK
When launched, the dbus-daemon will one read the configuration files /etc/dbus-1/system.conf or /etc/dbus-1/session.conf, depending on its launch option --system or --session.
On Tizen, the configuration file /etc/dbus-1/system.conf will include the configuration files of the sub-directory /etc/dbus-1/system.d and the configuration file /etc/dbus-1/session.conf will include the configuration files of the subdirectory /etc/dbus-1/session.d.
Services running on DBUS may (or should) provide a configuration file into on of these 2 sub-directories. That is the normal configuration process of DBUS services.
For example, the bluetooth service running at system level provides the configuration file /etc/dbus-1/system.d/bluetooth.conf.
The details of the configuration files is given in the manual pages of dbus-daemon.
This page describes an undocumented feature: the mechanism of SMACK security rules and their setting.
The SMACK aware DBUS daemon
During february 2012 Brian McGillion added support of SMACK into DBUS. He tried to push this change to upstream version 1.5, on a freedesktop.org issue #47581, which is still open. This work has been rebased on DBUS 1.6.12 (note than DBUS is now -Apr 2014- at version 1.8.0).
First, the DBUS daemon implements a new message bus message, similar to org.freedesktop.DBus.GetConnectionSELinuxSecurityContext, of name org.freedesktop.DBus.GetConnectionSmackContext:
- It expects one argument of type string: the unique or well-known bus name of the connection to query (such as :12.34);
- It returns one value of type string: the SMACK context of the connection as retrieved using getsockopt SO_PEERSEC.
Using DBUS, you can't rely on SMACK LSM to check policy of connections because the only connections that really exists are the connections to DBUS. Then if SMACK doesn't allow A to access B but allow both to access DBUS, A can interact with B using DBUS. That may be good or not depending on the case.
If it isn't good, the SMACK aware DBUS daemon allow to explicitly set the policy to apply using configuration files.
The configuration of a service can tell what policy to apply for the clients depending on their SMACK context as retrieved using getsockopt SO_PEERSEC.
For each SMACK label, a service can specify to allow or deny client. The below section setting files gives details on how to write SMACK policies in configuration files.
When a connection to DBUS is established, the DBUS daemon check the policies that are applying and records the set of allowed/denied pairings for that connection. The policies are of few kinds: GID, UID, SMACKID. Each of this policies is applied to create a set of allowed/denied pairings. The resulting set of pairing is the union of the 3 policies.
The policy check of SMACK can be shown by setting DBUS_VERBOSE=1 and looking for strings of kind "permission request subject (%s) -> object (%s) : %s".
Setting configuration files
The details of the configuration files is given in the manual page of dbus-daemon.
This section describes the policy setting for SMACK.
Let start with the example of what could be the file /etc/dbus-1/system.d/bluetooth.conf:
<busconfig> <policy smack="System"> <allow own="org.bluez"/> <allow send_destination="org.bluez"/> <allow send_interface="org.bluez.Agent"/> <allow send_interface="org.bluez.HandsfreeAgent"/> <allow send_interface="org.bluez.MediaEndpoint"/> <allow send_interface="org.bluez.MediaPlayer"/> <allow send_interface="org.bluez.Watcher"/> <allow send_interface="org.bluez.ThermometerWatcher"/> </policy> <policy smack="User"> <deny send_destination="org.bluez"/> </policy> </busconfig>
The value of the attribute smack of the element <policy> is a SMACK label.
Inside the <policy> elements, only the elements <allow> and <deny> are allowed. These elements are well documented in the manual page dbus-daemon.
When a new connection is checked against policy, its SMACK context (as retrieved using getsockopt SO_PEERSEC) is used as the subject label S.
Then the set of policy rules is scanned. For each policy rule <allow>/<deny> found, the SMACK label set by the attribute smack of the embracing <policy> is used as the object label O and the attribute of the <allow>/<deny> element is used to check the access A:
- read access for receive... attributes;
- read access for send... attributes;
- read/write access for own... attributes.
Then the smack database (as provided using smackfs) is queried to know if subject S has access A to object O. If it is the case, the <allow>/<deny> rule is added to the set of of rules to check.
Going back to the example, when the bluetooth daemon (bluez) running SMACK context System connects, DBUS checks the policies and sees that it is able to own the interfaces org.bluez. It also allows the communication from SMACK contexts System but it denies accesses from User.
It may be a strange behaviour (or a bug of the current version) that denied rules are checked against the smack database (as provided using smackfs) to be applied. If S has not access A to O and there is a <deny> rule, the deny rule will not be selected. Depending on the default policy, it may implies that S will be able to access O through DBUS despite the <deny> rule!
Then, be sure to define a default deny rule as below:
<policy context="default"> <deny send_destination="org.bluez"/> </policy>