Session bus vs system bus for an embedded system

[Simon McVittie]

On Wed, 18 Apr 2018 at 16:33:55 +0200, Alan Martinovic wrote:
> > If everything runs as uid 0, or if everything runs as a single nonzero
> > uid with no privilege separation, then you can probably apply a very
> > simple security policy where that uid can own all names and send all
> > messages.
> 
> I will end up having multiple dbus implementations on the system
> (BlueZ has its own, sdbus, dbus-daemon).
> The policies are defined in /etc/dbus-1/system.d#
> Do all the implementations read the same policy files, or should
> special consideration
> be taken?

I think you're mixing up more than one thing when you say
"dbus implementations".

A complete, working D-Bus setup consists of a central server process,
the *message bus*, and some *clients* that connect to the central server.

D-Bus is the protocol, like HTTP is a protocol.

dbus is the reference implementation of D-Bus: a software package that
implements the D-Bus protocol, containing libdbus, dbus-daemon and some
secondary tools like dbus-monitor.

The message bus and D-Bus clients will normally both use a D-Bus library
to talk the D-Bus protocol. dbus contains libdbus, which is the reference
implementation of the D-Bus protocol. Other library implementations are
available: GLib contains GDBus (part of libgio) and systemd contains sd-bus
(part of libsystemd). There are also implementations in non-C languages,
like dbus-java and dbus-sharp (C#).

There are also "bindings" which wrap a lower-level library (usually
libdbus) and provide a higher-level API or a different language interface:
QtDBus (C++ with Qt), dbus-python, Net::DBus (Perl), and so on. BlueZ
contains its own convenience layer around libdbus, which is basically a
private binding library.

dbus also contains dbus-daemon, which is the reference implementation of
the message bus. Other implementations of the message bus are available -
dbus-broker is an independent project to write a mostly-compatible
message bus, gdbus-daemon is a simple message bus provided with GDBus,
and dbus-sharp has its own C# message bus - but dbus-daemon is normally
the one that is used. Use dbus-daemon as your message bus unless you
have a good reason to choose something else.

dbus-daemon reads XML policies from /usr/share/dbus-1/system.d
and /etc/dbus-1/system.d. In theory the XML in those files is an
implementation detail of dbus-daemon (which is why they're documented
in the dbus-daemon man page, not in the D-Bus Specification), but some
other message bus implementations read them anyway, for interoperability
with existing software.

> Have currently specified this (have a service com.example.bigben):
> <busconfig>
>   <policy context="default">
>     <allow own="com.example.bigben"/>
>   </policy>
> </busconfig>

That is a valid policy allowing any user who can connect to the bus to
own that bus name. It's OK if you don't have any privilege separation.

If you will ever want privilege separation (uids with different
privileges) then you should use <policy user="root"> or
<policy group="campanologists"> or similar, instead of
<policy context="default">.

> And would like it to allow access to all apps to this service and all
> it's objects.

That would be:

<busconfig>
  <policy context="default">    <!-- or user= or group= as appropriate -->
    <allow own="com.example.bigben"/>
    <allow send_destination="com.example.bigben"/>
  </policy>
</busconfig>

You can put the two <allow> rules in separate <policy> elements if you
want to apply different policies for "can implement or impersonate the
com.example.bigben service" and "can use the com.example.bigben service".
For instance, it's common to have something like this:

<busconfig>
  <!-- Only root can run the widget manager daemon -->
  <policy user="root">
    <allow own="net.example.WidgetManager"/>
  </policy>

  <!-- Anyone can send requests to the widget manager -->
  <policy context="default">
    <allow send_destination="net.example.WidgetManager"/>
  </policy>
</busconfig>

Regards,
    smcv