Hi Joel,

On Sat, Jun 09, 2018 at 01:52:06PM -1000, Joel Roth wrote:
> [...]
> I have and use dbus apps on my system, However, as far as
> I'm aware, none of these programs has root privileges.
>
> As the pam/dbus/elogind/polkit mechanism is capable of
> handing out root authority, and as all software has bugs, I
> think we _can_ anticipate that bugs that create security holes
> will be uncovered in this stack. How much scrutiny did the
> developers devote? Did anyone ever consider security at
> through the whole stack? Probably the developers of each
> component do consider security in their own code.

I'm not sure but i think there is a miss-understanding here. Neither
dbus, elogind or polkit hand out "root" to other processes.

dbus is just a rather standarized IPC mechanism to allow for
communication between different processes. Also to make
system processes (running with root permission) to talk with
desktop applications. Of course, depending on the particular dbus
interface the system process provides and how it implements it,
this might become an attack vector. But in my oppinion this is
more an issue of the system process implementation and
dbus api interface definition of that service than of dbus it self.

polkit is some kind of authority which is used by many system
processes to figure out if a particular user or process is allowed
to invoke a (in most cases dbus) api of a (maybe system) service.
Wether access is granted depends on particular rules and maybe
system state - here comes the session management into
play. Many of the rules include a "the user must be
running an active local session" statement. polkit does not perform
any actions, it just veryfies that something can invoke something
and reports the result back.

polkit can be backed by two different session management systems,
either consolekit or logind. But some desktop environments rely
on a particular one.

elogind itself is one of these session management implementations
(providing the logind interface) and it tracks the sessions. In
addition it does some things to the cgroups of the user processes
and other weird things - its based on systemd-logind.

In order to run without root permissions the xorg xserver
relies on the session management. I think (not fully sure about this)
that the session management services can also prepare
permissions of device files, e.g. granting access to drm files
for the x-server. That why the non-setuid xserver needs elogind or
consolekit to be useable. If these are not to be used, the legacy
package with setuid wrapper is needed to run x from console

> Will someone who scrutinizes closer have a back door,
> is that likely be true for the foreseeable future?
>
> In a way, running others' code is like driving: putting
> oneself in the hands of strangers you've never met and
> might not trust for minute in person.

Well, you can say this about any software you run
which you did not compile by yourself and before that,
read and understood its whole source code and all of its
dependencies and interactions.


cheers
Andreas