about using privileged (KAuth) helpers: system dbus daemon on OS X?

[Thiago Macieira]

On domingo, 18 de setembro de 2016 23:39:36 PDT René J.V. Bertin wrote:
> On Sunday September 18 2016 09:32:35 Thiago Macieira wrote:
> > > So is it normal that the helper process is launched by the system dbus?
> > > If
> > > so, can someone please explain how the helper procedure is supposed to
> > > play
> > > out at the level of dbus communication?
> > 
> > dbus-daemon launches helper, helper sets the environment up to avoid any
> > leak of information from the daemon but also to setuid correctly, then
> > execs the target process.
> 
> I think your "target process" is what I've been calling the privileged
> helper, right? As far as I've understood from the code, dbus-daemon uses
> dbus-daemon-helper-tool to launch the helper required for the user's
> request. dbus-daemon-helper-tool is setuid root, meaning that anything
> exec'ed by it should have uid==euid==0 (or else it must do
> setuid(geteuid())). The helper would need to have uid==euid in any case,
> otherwise Qt or libdbus will typically refuse to work, and if it doesn't
> have euid==0 it wouldn't be privileged.

I have no idea what other kind of helper there may be. There's only "dbus-
daemon-launch-helper", which is setuid root, but setuids to the service's 
user. The launched service only sees its own UID, never 0.

> So we have a user application (say, ksysguard) that calls DBus routines to
> launch a privileged helper process (ksysguardprocesslist_helper), a master

That's not how it works. An application asks for a service, like org.bluez. If 
there's a .service file that matches that, it specifies the executable name 
along with the user ID to run under. Then dbus-daemon runs dbus-daemon-launch-
helper and that will setuid, clean the environment, then exec the target 
executable.

Once the launched executable connects to the system bus and claims the service 
name, the daemon delivers the message that triggered the loading.

> Is it the dbus-daemon-helper-tool setting-up of the environment that ensures
> that the ksysguardprocesslist_helper can connect to the user's session
> dbus? If so, how? dbus-daemon-helper-tool is supposed to run with the
> user's UID and EUID=0, but if it can read the user's
> DBUS_SESSION_BUS_ADDRESS, why can its children not read it?

No. Nothing ensures that anything can connect to the user's session bus. 
System services do not connect to session busses.

> Then there's the fact the system dbus runs as yet another user
> ("messagebus"; 102 on my Linux box, 500 on OS X) and that's probably the
> UID with which the dbus-daemon-helper-tool runs.

No, that's the UID for dbus-daemon running as the system bus. The helper runs 
as root, then setuid()s, as described above.


> If the privileged helper (slave) is supposed to connect to the system dbus
> when launched via dbus-daemon-helper-tool, how/why does it do so on Linux?

The helper does not connect to the any bus. The executable that it launches is 
expected to connect ot the system bus, as described above.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center