9

How can an unprivileged user prevent a D-Bus service from launching? For example, /usr/share/dbus-1/services/org.bluez.obex.service is started by the session bus. There doesn't seem to be a way to "blacklist" it.

It is the session bus that my question refers to. I would like to know if it is possible to prevent specific services from starting on the session bus.

Elder Geek
  • 36,023
  • 25
  • 98
  • 183
Nathan Osman
  • 32,155
  • An unprivileged user? Meaning one without sudo privilege? Does said user have access to the physical hardware? – Elder Geek Nov 03 '16 at 15:47
  • @ElderGeek no, not necessarily. – Nathan Osman Nov 03 '16 at 16:13
  • Could you explain exactly what you mean then? I would hope that an unprivileged user couldn't prevent a service from starting. Is this something that is occurring that you are trying to stop or something you are trying to accomplish? – Elder Geek Nov 03 '16 at 16:25
  • @ElderGeek there are two D-bus... buses (:P) that applications can interact with. The system bus controls aspects of the system that are common among users and the session bus provides access to services specific to the current user. It is the session bus that my question refers to. I would like to know if it is possible to prevent specific services from starting on the session bus. – Nathan Osman Nov 03 '16 at 16:50

1 Answers1

4

The standard systemwide and per-session message bus setups are configured in the files /usr/share/dbus-1/system.conf and /usr/share/dbus-1/session.conf. These files normally a system-local.conf or session-local.conf in /etc/dbus-1; you can put local overrides in those files to avoid modifying the primary configuration files.

The configuration file is an XML document. It must have the following doctype declaration:

I believe you need to modify /usr/share/dbus-1/session.conf which is what /etc/dbus-1 in ubuntu is linked to.

Note: Limits are normally only of interest on the systemwide bus, not the user session buses but I think you can use them on the session bus.

The element defines a security policy to be applied to a particular set of connections to the bus. A policy is made up of and elements. Policies are normally used with the systemwide bus; they are analogous to a firewall in that they allow expected traffic and prevent unexpected traffic.

Policies applied later will override those applied earlier, when the policies overlap. Multiple policies with the same user/group/context are applied in the order they appear in the config file.

You can likely just tack something like this on the end of /usr/share/dbus-1/session.conf prior to the </busconfig> line which would allow access for those in the lp group and deny it for everyone else. Of course you'll need to modify this to match your environment and your needs.

<policy group="lp">
    <allow send_destination="org.bluez"/>
    <allow send_destination="org.bluez.obex"/>
  </policy>

  <policy context="default">
    <deny send_destination="org.bluez"/>
    <deny send_destination="org.bluez.obex"/>
  </policy>

Sources:

https://github.com/netblue30/firejail/issues/796 http://www.linuxfromscratch.org/blfs/view/svn/general/dbus.html https://dbus.freedesktop.org/doc/dbus-daemon.1.html https://github.com/ghent360/bluez/blob/master/src/bluetooth.conf

Elder Geek
  • 36,023
  • 25
  • 98
  • 183