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
