:: Re: [DNG] xserver-xorg-core in Debi…
Top Pagina
Delete this message
Reply to this message
Auteur: Adam Borowski
Datum:  
Aan: dng
Onderwerp: Re: [DNG] xserver-xorg-core in Debian unstable now requires libsystemd0
On Fri, Jul 01, 2016 at 06:00:03AM +0200, Adam Borowski wrote:
> On Thu, Jun 30, 2016 at 09:09:17PM +0200, Enrico Weigelt, metux IT consult wrote:
> > Does anyone know what these pieces of code *actually* do ?
>
> As no one more knowledgeable responded, here's my understanding:


Turns out this remark was important: some more clue here would be nice.
Tobias Hunger just shown me a nasty issue (he's banned from dng).

> 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


There's a bug in evdev: normally, when a process listens to cooked events
(keyboard, etc), they get delivered only when the right VT is active. Not
so much with raw events: once a process gets hold of such a device, it will
receive events even when VT was switched.

Listening to events regardless of VT is needed for some obscure inputs, but
for typical ones (keyboard, mouse, joypad, wacom, etc) they should go
strictly to the active VT.

Currently, programs that use raw events can only consciously ignore those
they shouldn't receive. Which is easy to get wrong, either accidentally or
maliciously. For the former, Mir guys did it, for the latter, running Xorg
as an unprivileged user means easy LD_PRELOAD/ptrace fun.

More info in the commit message of
https://git.kernel.org/linus/c7dc65737c9a607d3e6f8478659876074ad129b8


Obviously, systemd guys instead of the obvious fix of censoring events based
on the active VT invented a yet another daemon (part of logind) that
actively does revocation over dbus. I already see two potential ways to
subvert that (as in "a vague idea" not "working exploit" though): VT
switches are atomic, manual revocation anything but.

But even if I really hate their solution, the problem remains real.


And I don't have enough clue to comfortably fix this myself; my only commits
anywhere near VT are to ANSI code handling.


Meow!
--
An imaginary friend squared is a real enemy.