Rootless X [LWN.net]

By Jonathan Corbet
July 15, 2009

Complexity has long been known to be the enemy of security. A code base which is small and straightforward can be verified, with a reasonable degree of trust, to do what it is supposed to do and only that. As the code becomes more complex and harder to understand, that sort of verification becomes increasingly difficult. For this reason, developers try to separate code requiring privilege from that which doesn't. Any code which can be run in a nonprivileged mode is code which is relatively unlikely to create security problems, and the code which is left can, hopefully, be reviewed to a level sufficient to give the required degree of confidence in its security.

Now consider the X window system. It is a massive body of code with a relatively small development community. Some of the code is truly ancient and hasn't seen much real developer attention in years. As with most projects, some of the code is of higher quality than the rest. The X server performs a complex task - based on a complicated protocol - for almost every Linux user. Sometimes it is even exposed to the full Internet. And the X server runs as root, with full privileges. The actual number of security problems found in X over the years has been relatively small, but it is not hard to believe that it is more a matter of luck and a lack of attackers than the inherent quality of the X code base.

Worries about the X server are not new; that is why there has been discussion of running it in a nonprivileged mode for several years. Much of the work which has been done on display graphics has had this goal in mind. All that notwithstanding, Linux distributions still install X as a setuid program. It just has not been possible to enable a nonprivileged X server to get its job done without opening up the system as a whole.

Those days are just about done. The Moblin project is now claiming that it will be the first distribution to ship with a nonprivileged X server. Where Moblin goes, others will certainly follow.

Some details of how this work was done were posted to the xorg-devel list by Jesse Barnes at the beginning of July. According to Jesse, finishing out this multi-year job was "pretty easy." It seems that the pieces are in place now - at least for some graphics hardware - to the point that a few hours of work got the job done. It seems like an almost anti-climactic end to such a long-term challenge. But, of course, the work which has made this result possible has been ongoing for a long time.

The biggest piece is the kernel mode setting (KMS) code which was merged for 2.6.29. Prior to KMS, the X.org server was charged with finding the hardware and driving it directly from user space. Needless to say, this sort of access requires root privilege, since it can easily be used to compromise the system. KMS (and the associated graphical memory management code) turns graphical hardware into something closer to a normal device with a normal kernel driver - albeit a rather complex and specialized sort of "normal" device. The hardware manipulations requiring privilege have been isolated into a relatively small piece of kernel code; they are now separated from the rather larger body of code implementing the X protocol.

That means that X code accessing the hardware can now be run unprivileged as long as it has the ability to open the appropriate device file. The server must also have the ability to open related device files: input devices, the virtual console, and so on. But that is a problem that has been solved for years; the login process can easily change the ownership of those files so that an unprivileged server can access them but the world as a whole cannot.

What's left is some detail work. Some of the ioctl() calls for direct rendering are currently root-only; Jesse thinks that they can be made generally available in a safe way. There may be some small additions to the driver ABI to allow the final root-only operations to be pushed onto the kernel side. But that's about it.

Of course, user-mode X will currently only work with Intel chipsets, since those are the only ones with full KMS support at this time. Radeon drivers are acquiring that support quickly, though, and may be able to support no-root operation in the relatively near future. That leaves NVIDIA as the usual odd chipset out of the big three; the current Nouveau feature matrix suggests that it will be some time yet before the requisite features are available there.

It may also be a little while until we see no-root support in more general-purpose distributions. Moblin has a relatively narrow focus on Intel hardware, by virtue of the fact that it's still mostly Intel people who are doing the work. Distributors who need to make things work on whatever hardware happens to be present may approach a change of this magnitude with a bit more caution. Still, X without root is clearly in the future, and the near future at that.

(Log in to post comments)

Rootless X

Posted Jul 16, 2009 19:38 UTC (Thu) by jlokier (guest, #52227) [Link]

At least in other video card drivers I've looked at, and some I've worked on (not in Linux), modesetting is pretty complicated stuff because it involves so many hardware-specific quirks, tables full of obscure numbers, and probably touches more hardware registers than any other feature including 3D acceleration.

That's not to say the rest is easy, but modesetting is usually more complicated than you'd think, for something which sounds so trivial.

Also it tends to require more hardware-specific hacks. At least with 3D rendering, you can see if it works and then it's likely to work the same on all boards with the same generation GPU. The same can't be said for modesetting.

Finally, modesetting is very important, but it's not as much fun as rendering.

Rootless X

Posted Jul 19, 2009 18:29 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

Fedora 11 supports Nouveau with KMS but you have to pass a boot option

http://fedoraproject.org/wiki/Features/NouveauModesetting

Fedora 12 likely will have it on by default since Red Hat hired Ben Skeggs, one of the primary developers during the last release cycle to support development.

Not really "working"

Posted Jul 16, 2009 16:33 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

From Dave's blog:

...granted it oopses soon afterwards...

Doesn't sound like "working" to me. Just my skeptical $0.02.

(Not meant to impugn the work of the Moblin devs and Dave A.)

Rootless X

Posted Jul 16, 2009 17:14 UTC (Thu) by jsbarnes (guest, #4096) [Link]

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.

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.