User: Password:
|
|
Subscribe / Log in / New account

Rootless X

Rootless X

Posted Jul 16, 2009 17:14 UTC (Thu) by jsbarnes (guest, #4096)
In reply to: Rootless X by i3839
Parent article: Rootless X

Yeah I mentioned that in my post to the xorg-devel list. Dave's work pre-dated GEM for example (turns out GEM made this easier too), but I don't think his bits ever made it upstream. The X and kernel parts of this are fairly straightforward now (due to the bits Jon mentioned); however the distro side of things isn't trivial. The distro has to take care to set ownership and permissions on the various devices nodes X uses properly; input, ttys and DRM for instance. And user switching brings its own challenges (in fact this is one of the problems Dave brought up recently), the switcher has to take care to prevent the old user from being able to see any of the new user's data. So the part of the work I did definitely isn't the whole story.

Anyway Dave definitely deserves a lot of credit here; not only did he do some of this last year, he also wrote most of the kernel mode setting code which made it possible.


(Log in to post comments)

Rootless X

Posted Jul 17, 2009 16:32 UTC (Fri) by i3839 (guest, #31386) [Link]

Just curious, but is Moblin's goal to run X as a special non-root user or as the logged in user?

Avoiding informationa leakage, especially keyboard input, seems like a difficult problem. Easiest seems for the kernel to stop sending data to already open file descriptors when permissions or ownership change. It's unclear how userspace could handle this without help.

Rootless X

Posted Jul 17, 2009 17:29 UTC (Fri) by jsbarnes (guest, #4096) [Link]

Arjan has some ideas about it; having some sort of revoke syscall would make things easy. But now that X uses HAL for getting at input devices, we could use it instead. HAL could notify the server that its input devices have been unplugged at user switch time; any remaining users of the input device nodes after that would be assumed to be malicious and could be killed by simply looking at the list of processes associated with those files. Combine that with an ownership change, and the input part of user switching is solved.

I think we still need to work on the DRM master/auth scheme though, maybe allowing set/drop master to be an unprivileged call (only allowing one master of course).

Rootless X

Posted Jul 18, 2009 9:59 UTC (Sat) by i3839 (guest, #31386) [Link]

> any remaining users of the input device nodes after that would be assumed
> to be malicious and could be killed by simply looking at the list of
> processes associated with those files.

That doesn't seem safe because it is very racy. E.g. two malicious processes ping-pong the fd via unix domain sockets. With some bad luck you either kill the wrong one or don't see the fd at all. Alternative race is dup2'ing the fd around, or simply doing a fork() at the right time.

This also needs root access, which is needed to do ownership changes anyway, but unlike changing ownership chasing processes and killing them is tricky and dangerous. Interesting exploit: Somehow letting a root process open an input device (e.g. via a symlink) and let it get killed.

Please don't go that way, it will cause problems.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds