Hi Andreas, And thanks for the explanations!
Andreas Messer wrote: > 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. I may have confused ipc with rpc. > 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. ISTR that vdev can give process-specific views of /dev, and appears to offer a different, lightweight option in that direction.[1] Not clear how much these overlap, pretty clear that vdev doesn't have anything to say about cgroups. > 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 So, I'm looking into the security implications of setuid X, and found this helpful explanation on stackexchange:[2] X11 apps run as a non-root user. However, on most platforms the X11 drivers run as root, so they can access the display hardware. This introduces the risk that a malicious app might be able to exploit some security vulnerability in the X11 code and use it to become root. This is a serious risk, because X11 is a complex system with a tremendous amount of code, and all it takes is one security vulnerability anywhere in that code to make a privilege escalation attack possible. This is indeed a concern. Enabling remote attacks. If I run X11 on my Linux machine, does that make it easy (or possible) for remote attackers to "hack" my machine? The answer is no. Remote attackers have no way to access or talk to X11, so running X11 on my machine does not make my machine insecure. > > 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. In this instance, I have heard people saying "setuid X is a security risk, we should switch over to PAM. According to this reference, it isn't such a risk. The underlying idea of PAM seems reasonable to me, however, the complexity of the stack above PAM in LOC leads me me question if my single-user system needs this. I consider myself fortunate to have the choice! greets, > cheers > Andreas 1. https://judecnelson.blogspot.com/2015/01/introducing-vdev.html 2. https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure#4646 -- Joel Roth _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
