dbus: enhancements to use privileged services via the system bus and run a session bus over a remote X11 connection

[RJVB (René Bertin)]

This may be frowned-upon or downright incompatible with SIP, but the ${prefix}/libexec/dbus-daemon-launch-helper utility should be owned by root:messagebus and setuid root in order to be considered by the system dbus-daemon . It is used to launch dbus services that should run as root, and indeed the setuid bit is set on this file on Linux.

The dbus portfile should thus include 2 additional commands in the post-activate step, if this functionality is to work

    file attributes ${prefix}/libexec/dbus-daemon-launch-helper -owner root
    system "chmod u+s ${prefix}/libexec/dbus-daemon-launch-helper"

What's the current consensus on running a system dbus daemon on OS X?

[RJVB (René Bertin)]

I've been hacking some more at getting privileged DBus helpers to work, for instance the one in port:kf5-libksysguard that is used to control process priority or to send signals to processes running with a different UID.

Edit: removed description of obsolete hacks.

[RJVB (René Bertin)]

I've been doing some more work on system bus support, and being able to use it for with privileged services (like the helpers for the KAuth framework).

This stands a good chance of being upstreamed.

[RJVB (René Bertin)]

Can someone please change the title of this ticket?

dbus: enhancements to use privileged services via the system bus and run a session bus over a remote X11 connection

I have been trying to add the possibility to start a dedicated session bus when logged in remotely using ssh+X11, one not using launchd (launchctl) and independent of any session bus that might be running locally. That feature now seems to work, but remains experimental and could use some testing in the wild!

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

This stands a good chance of being upstreamed.

Discussion/ticket link?

Not that I plan on looking at this, but I would strongly advise that we not patch DBus and run our own setuid daemon outside of launchd. If this configuration is secure, then we can provide it once upstream starts supporting it.

[RJVB (René Bertin)]

For now the discussion has been on the dbus mailing list.

Just FYI: the patch doesn't change anything to the underlying mechanism, and is indeed secure in the sense that an authorisation procedure must be completed before the setuid helper is used to execute a well-defined, privileged service (and only that service). Without an authorisation mechanism (provided by the KF5 KAuth framework and based on Apple's Security framework *plus* root-owned files in ${prefix}/etc/dbus-1/system.d the setuid helper is simply never called.

The patch changes a few detail during the initialisation of the privileged service executable, which expects to connect to the system dbus. The init code tries to obtain the addresses (sockets) of 3 different bus types (session, system and "master"). The privileged helper exec runs in a tightly controlled environment, containing only the system bus address;

• on Linux, the init routines will thus set the other addresses to "autolaunch", meaning that a daemon will be launched for them if and when required. In practice that will not happen in this particular situation.
• on OS X the init routines only consider(ed) a session bus launched via launchd and a system bus using a hardcoded socket path. That means that for the privileged service exec, the session and master bus addresses are not set to "autolaunch" but remain empty. The unpatched code will raise an early error in that case, at a point where it doesn't even know which bus is going to be used. My patch simply uses the fact that autolaunch isn't required in this scenario; the initial set-up will succeed if the requested bus address is known because for the 2 irrelevant bus addresses it doesn't matter if they equal autolaunch or NULL.

As to "running our own setuid daemon": that's *not* the correct wording. The dbus daemon doesn't run as root; even the system bus daemon runs as the messagebus user, which isn't even in the admin group. There's a setuid *helper*, just like port:policykit provides. That helper can only be executed by root and by the messagebus user, and requires a service ID as argument ... which will be rejected if called without authorisation:

> sudo qdbus --system org.kde.ksysguard.processlisthelper
Error: org.freedesktop.DBus.Error.AccessDenied
Rejected send message, 1 matched rules; type="method_call", sender=":1.33" (uid=0) interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination="org.kde.ksysguard.processlisthelper" (uid=0)

FWIW, Apple's Security API docs also describe a setuid helper as on of the possible means to perform privileged operations after obtaining authorisation.

[RJVB (René Bertin)]

Oh, and the patch-allow-setuid.diff patch is obsolete.

[raimue (Rainer Müller)]

Is this autogen.sh really necessary? This file is already distributed with dbus. By the way, ${workpath}/${worksrcdir} can be replaced with ${worksrcpath}.

[RJVB (René Bertin)]

Ah, right. I'd made a mistake in setting configure.cmd which led to a "autogen.sh not found error" and didn't check any further. Thanks. I'll probably have to patch it (to avoid doing a developers' build) but that's no problem.

[RJVB (René Bertin)]

That said, the difference between the shipped autogen.sh and the one attached is minimal; I'll replace the copy in ${filespath} with a patch to obtain the same contents.

[RJVB (René Bertin)]

Re: privileged services: here's an extract from ${prefix}/share/doc/dbus/system-activation.txt :

Details:

Setuid applications have to used only when absolutely necessary.
In this implementation I have an single executable,
dbus-daemon-launch-helper, with the ownership root:dbus.
This has the permissions 4750, i.e. u+rwx g+rx +setuid.
It is located in /usr/libexec/ and thus is not designed to be invoked by a
user directly.

The helper must not be passed input that can be changed maliciously, and
therefore passing a random path with user id is totally out of the question.
In this implementation a similar idea as discussed with Davids' patch was
taken, that to pass a single name argument to the helper.
The service filename of "org.me.test.service" is then searched for in
/usr/share/dbus-1/system-services or other specified directories.

If applications want to be activated on the system _and_ session busses, then
service files should be installed in both directories.

A typical service file would look like:

[D-BUS Service]
Name=org.me.test
Exec=/usr/sbin/dbus-test-server.py
User=ftp

This gives the user to switch to, and also the path of the executable.
The service name must match that specified in the /etc/dbus-1/system.d conf file.

Precautions taken:

* Only the bus name is passed to the helper, and this is validated
* We are super paranoid about the user that called us, and what permissions we have.
* We clear all environment variables except for DBUS_VERBOSE which is used for debugging
* Anything out of the ordinary causes the helper to abort.

[RJVB (René Bertin)]

supersedes patch-enable-x11-autolaunch.diff

[raimue (Rainer Müller)]

Replying to rjvbertin@…:

That said, the difference between the shipped autogen.sh and the one attached is minimal; I'll replace the copy in ${filespath} with a patch to obtain the same contents.

I think you could avoid the patch completely by doing this in two steps:

use_autoreconf yes
autoreconf.cmd ./autogen.sh --no-configure

However, you will need to review the added build dependencies thoroughly. Most likely you will need to add autoconf/automake/libtool once again after these statement as they are automatically cleared when setting autoreconf.cmd.

[raimue (Rainer Müller)]

Correcting myself, of course I meant it like this:

use_autoreconf    yes
autoreconf.cmd    ./autogen.sh
autoreconf.args   --no-configure

[RJVB (René Bertin)]

Replying to larryv@…:

Replying to rjvbertin@…:

This stands a good chance of being upstreamed.

Discussion/ticket link?

​https://bugs.freedesktop.org/show_bug.cgi?id=97927

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

There has not been much recent activity on the upstream bug report.
Is this still an active improvement?

[RJVB (René Bertin)]

Hah, periodically I remember I had this ticket open. I guess I've been putting off working on it until I'm obliged to upgrade my dbus port.

In practice I rarely ever use privileged features over the system dbus. It happens a bit more often that I start a session dbus while logged in remotely, but even that is something I don't need most of the time. That's not to say I won't maintain at least the 2nd feature though.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

So should we keep this ticket open?