[MacPorts] #52257: dbus-daemon-launch-helper should be setuid root
#52257: dbus-daemon-launch-helper should be setuid root -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: dbus -------------------------+-------------------------------- 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? -- Ticket URL: <https://trac.macports.org/ticket/52257> MacPorts <https://www.macports.org/> Ports system for macOS
#52257: dbus-daemon-launch-helper should be setuid root --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: dbus | --------------------------+-------------------------------- Comment (by rjvbertin@…): 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. With the attached patch libdbus will now accept to run setuid, have a better chance at finding the session bus socket when run through sudo if the following line is added to /etc/sudoers (using `visudo` evidently): {{{ Defaults env_keep += "DBUS_LAUNCHD_SESSION_BUS_SOCKET" }}} and privileged workers actually seem to work if the system dbus is running and one has used the following magic formula at least once in the current login session: {{{ sudo launchctl setenv DBUS_LAUNCHD_SESSION_BUS_SOCKET $DBUS_LAUNCHD_SESSION_BUS_SOCKET }}} -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:1> MacPorts <https://www.macports.org/> Ports system for macOS
#52257: dbus-daemon-launch-helper should be setuid root --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: dbus | --------------------------+-------------------------------- Comment (by rjvbertin@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:2> MacPorts <https://www.macports.org/> Ports system for macOS
#52257: dbus-daemon-launch-helper should be setuid root --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: dbus | --------------------------+-------------------------------- Comment (by rjvbertin@…): 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! -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:3> MacPorts <https://www.macports.org/> Ports system for macOS
#52257: dbus: enhancements to use privileged services via the system bus and run a session bus over a remote X11 connection --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: dbus | --------------------------+-------------------------------- -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:4> MacPorts <https://www.macports.org/> Ports system for macOS
#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 | --------------------------+------------------------ Changes (by larryv@…): * owner: macports-tickets@… => mcalhoun@… * cc: mcalhoun@… (removed) Comment: Replying to [comment:2 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. -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:5> MacPorts <https://www.macports.org/> Ports system for macOS
#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
#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@…): Oh, and the `patch-allow-setuid.diff` patch is obsolete. -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:7> MacPorts <https://www.macports.org/> Ports system for macOS
#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 raimue@…): Is this `autogen.sh` really necessary? This file is already distributed with dbus. By the way, `${workpath}/${worksrcdir}` can be replaced with `${worksrcpath}`. -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:8> MacPorts <https://www.macports.org/> Ports system for macOS
#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@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:9> MacPorts <https://www.macports.org/> Ports system for macOS
#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@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:10> MacPorts <https://www.macports.org/> Ports system for macOS
#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@…): 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. }}} -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:11> MacPorts <https://www.macports.org/> Ports system for macOS
#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 raimue@…): Replying to [comment:10 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`. -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:12> MacPorts <https://www.macports.org/> Ports system for macOS
#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 raimue@…): Correcting myself, of course I meant it like this: {{{ use_autoreconf yes autoreconf.cmd ./autogen.sh autoreconf.args --no-configure }}} -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:13> MacPorts <https://www.macports.org/> Ports system for macOS
#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@…): Replying to [comment:5 larryv@…]:
Replying to [comment:2 rjvbertin@…]:
This stands a good chance of being upstreamed.
Discussion/ticket link?
https://bugs.freedesktop.org/show_bug.cgi?id=97927 -- Ticket URL: <https://trac.macports.org/ticket/52257#comment:14> MacPorts <https://www.macports.org/> Ports system for macOS
participants (1)
-
MacPorts