Session bus vs system bus for an embedded system

[Alan Martinovic]

Hey,
thanks. :)

> 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?

Also, Is it possible to expose all the service objects with a single policy?
Am trying to make the most of what I believe are the policy docs (are
they? :) ):
https://linux.die.net/man/1/dbus-daemon

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

And would like it to allow access to all apps to this service and all
it's objects.
Am I on the right path?


On Wed, Apr 18, 2018 at 1:54 PM, Simon McVittie <smcv at collabora.com> wrote:
> On Wed, 18 Apr 2018 at 10:55:28 +0200, Alan Martinovic wrote:
>> Given the issues and the nature of the system,
>> I kind of assumed it makes sense to
>> ignore the session bus and just base everything
>> on the system bus.
>
> This is probably true. Because the system bus is a shared resource for
> the whole system, you will need to set up some sort of security model
> that matches your security policy (which uids can own which names, which
> uids can send which messages, etc.).
>
> 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.
>
> Tools like dbus-monitor default to the session bus (because it's the
> common case, and the only one you can debug without root privileges)
> but can be directed to the system bus with a --system option. Similarly,
> sample code will normally use the session bus, but it should be easy to
> divert it to the system bus (for example by changing Gio.BusType.SESSION
> to Gio.BusType.SYSTEM in PyGI-based code).
>
>> Is there value in getting the session bus working
>> an use it instead of a system bus for a single user
>> embedded system?
>
> Probably only if you are reusing existing session-bus services
> (PulseAudio, Tracker, MPRIS, that sort of thing) which are not designed
> to use the system bus.
>
>> It's a GUI-less, headless system that developers
>> access via UART or SSH, and physical users never
>> access directly.
>
> If you want a session bus on such a system, you will have to arrange
> to have one yourself, either by using the systemd user service,
> dbus-run-session(1), dbus-launch(1), or starting dbus-daemon the hard way.
> https://lists.debian.org/debian-devel/2016/08/msg00554.html has an
> overview of the various ways you might get a session bus.
>
> If your device boots using systemd then I'd recommend making
> `systemd --user` responsible for starting your user's session bus,
> probably in conjunction with `loginctl enable-linger $username` to get
> `systemd --user` started during boot.
>
> The error message that you saw (involving a $DISPLAY for X11) is
> libdbus failing to use its last-resort mechanism to get a dbus-daemon
> ("autolaunching"), which relies on X11. On a properly-set-up system,
> that code path should never be necessary or reached.
>
>     smcv
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dbus