[MacPorts] #52257: dbus: enhancements to use privileged services via the system bus and run a session bus over a remote X11 connection

[MacPorts]

#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