#52257: dbus: enhancements to use privileged services via the system bus and run a session bus over a remote X11 connection --------------------------+------------------------ Reporter: rjvbertin@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: dbus | --------------------------+------------------------ Comment (by rjvbertin@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:6> MacPorts <https://www.macports.org/> Ports system for macOS