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
signature.asc
Description: PGP signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng