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.