Re: [dev] swc: A small Wayland compositor

From: Markus Teich <markus.teich_AT_stusta.mhn.de>
Date: Sun, 26 Jan 2014 02:09:31 +0100

Michael Forney wrote:
> I've added a minimal example window manager in example/. It can be built with
> "make example", and run with "launch/swc-launch example/wm". Note that
> swc-launch needs either setuid root or to be run as root in order to open
> input devices and to obtain DRM modesetting privileges.
>
> Possible security concern: swc-launch passes opened input device file
> descriptors to the user-specified display server process (which is run with
> reduced privileges). However, it also switches to a new unused VT, and revokes
> them when this VT is switched away from. One potential issue with this is that
> it doesn't prevent a malicious program from pretending to be swc-launch and
> starting a trusted display server to appear normal, but underneath intercept
> any key presses. Though, I'm also not sure that the situation is any better on
> X ("xev -id window-id" can dump input events sent to window-id).
>
> Weston solves this problem by hardcoding the display server path in
> weston-launch. For swc, this would imply a separate launcher program for each
> window manager, which doesn't seem like a good solution to me. On a
> single-user development machine, it is quite convenient to be able to run, for
> example, "swc-launch -- valgrind example/wm" to debug crashes. However, I do
> see the potential risk. Another solution could be having a configuration file
> in /etc containing a list of allowed display servers.
>
> Thoughts?

Heyho,

why do you not put the VT switching and input dev fd handling code into swc. In
this case the developer implementing a wm would have to do priviledge dropping.
This leads to one suid executable per wm without the need of a launcher. Am I
missing something here?

--Markus
Received on Sun Jan 26 2014 - 02:09:31 CET