On Tue, Jun 12, 2018 at 10:49:35AM -1000, Joel Roth wrote: > Hi Andreas, > > And thanks for the explanations! > > Andreas Messer wrote: > > Hi Joel, > > dd> > 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.
Thanks for the info. The cgroup thing, well I have no idea if that would be really needed to run a desktop system. I was surprised by this when seen the first time. I think system-logind (and in turn elogind) use it to figure out if a process belong to a particular session. system-logind can/will also set various limits while elogind does not as far as i know. While I can understand the session management usecase, I'm not sure if the other crap is really required, especially since there are exisiting solutions for cgroup management. > [...] > 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. Fun fact about this is, having Xserver run as non-root wont protect you either. There were some kernel/xorg combinations which suffered from an anoying bug in direct rendering manager - I did not fully understood if it was the xorg driver's fault or a kernel issue. This bug made the whole graphics system crash, crash that even the tty console was not usable anymore (only ssh). And this bug could be simply triggered by proper combination of some opengl commands (e.g. Dragging around in kicad was enough to trigger it) Its probably not to hard to prepare a website to make a (possibly particular) browser to issue the correct opengl command sequence to run into the problem. And if such a thing exist, well I don't know much about direct rendering structure, but I'm afraid the step to make the kernel execute something in elevated context is not too big. > 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! > [...] Yes, I actually did not thought a lot about this. Have to admit I just adopted to the new way here. I'm not sure, but I think the graphical user switch is only possible with the session management thing. And since it is possible I use this now and then - switch to another session while someone else of the family is logged in and has locked the system. cheers, andreas
signature.asc
Description: PGP signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
