On Thu, Jun 30, 2016 at 09:09:17PM +0200, Enrico Weigelt, metux IT consult wrote: > On 28.01.2016 17:16, Adam Borowski wrote: > > <snip> > > Does anyone know what these pieces of code *actually* do ?
As no one more knowledgeable responded, here's my understanding: Certain operations needed by an X driver require privileged access to hardware; what exactly is needed differs per driver. This can be either done in userspace (the old way) or in the kernel (KMS, DRM, etc). For the latter to work, the kernel must have support for your graphics card; there's a large number of old cards where no one bothered to do this work, and most likely no one ever will. Also, while [k]freebsd does support KMS/DRM these days, it tends to lag behind Linux; I believe hurd didn't even start. The access is usually done via a device node. Nodes which require root/cap can be used to damage the system in some way, be it subverting security, crashing the machine or perhaps even physically damaging the hardware. Thus, we need to somehow let the X server open those nodes. This can be done in following ways: a> by making the X server setuid. This is the old way. b> using a setuid helper c> having systemd-logind open the node and pass a file descriptor d> having a smart /dev Obviously, a> is bad because the X server is a complex program with a large attack surface. Doing b> would be portable and init system agnostic, thus the systemd crowd won't have it. Thus, they picked c> (although it _is_ a Rube Goldberg variant of b> that employs systemd and dbus). When/if vdev takes off, one of its prominent uses is d>. Otherwise, a solution for Devuan could be to implement b>. However, it's not that urgent a matter because: * all modern cards on Linux have KMS * for ancient cards and Hurd, there's a slightly improved variant of a> in xserver-xorg-legacy. * b>, c> and d> can be subverted by means of controlling _your_ process, be it LD_PRELOAD, ptrace, etc. Here I'm not certain as I'm not sure I have a non-KMS card around, but it _seems_ to me that current stretch/systemd fails spectacularly: 1. despite all the talk about avoiding setuid, when started from lightdm (ie, 99% of uses) I see Xorg running as root, 2. when started via startx, Xorg is ptraceable. I'd recommend investigating thoroughly before bashing, though. Meow! -- An imaginary friend squared is a real enemy. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
