Slashdot Mirror
Moblin Will Run X Server As Logged-In User, Not Root
nerdyH writes "An architect of the Moblin Project has announced that Moblin 2.0 for netbooks and nettops is the first Linux distribution to run the X server as the logged-in user, rather than SUID'd to root. The fix to this decades-old security liability comes thanks to 'NRX' (No-root X) technology reportedly developed by Intel, Red Hat, and others in the X community, and the Moblin-sponsored 'Secure X' project. Besides making Linux netbooks a lot more snoop-proof, it seems like this could lead to an X-hosting renaissance of sorts, since you wouldn't be risking the whole system just to open up a specific user's account to remote X servers."
frost nixon
This is something that is long overdue.
Who will guard the guards?
Just got fixed by this. To be honest, I don't know how they've done it, but I know this is a good thing. This will make X and linux more secure and I can only applaud that.
Linux's SUID X server problem has been kind of a "dirty little secret" for many years. Most modern distributions include a few crude workarounds, such as dimming the display and then freezing X whenever the user is asked to type in a root password. Getting rid of the SUID bit altogether ought to make netbooks powered by Moblin technology much more difficult to snoop on over the network.
This does not make sense. Graphical sudo wrappers have nothing to do with X being suid, and neither does anything to do with network traffic.
It seems likely that with NRX technology, you could run X apps over a network with much less risk to the app server (the system that runs the "X client" component, in the backwards terminology of X).
This is actually backwards, the only place there's less risk is for the system that the X server is running on.
I'm not sure I grasp the concept of X Hosting, and how this non-SUID server would help that.
X is not required to be running on the remote system for X11 forwarding over SSH. Even running an Xvnc server doesn't require it to be SUID. This seems to be entirely a local security gain for users who will be interacting with local graphics hardware.
But running apps remotely and having them display on a local X server _NEVER_ required root access of any kind on the remote server....
The article repeats the common misunderstanding: "in the backwards terminology of X"
What exactly is backwards about this? X is the server, and the apps are clients.
Think about it: The client initiates the conversation with the server. The client tells the server what to do.
How is this backwards?
> it seems like this could lead to an X-hosting renaissance of sorts,
> since you wouldn't be risking the whole system just to open up a
> specific user's account to remote X servers.
What a clueless statement. Somebody doesn't understand how X works. The server part that runs SUID root has never ran on the app server.
What this does do is stop a random remote app getting to root on your workstation but any local exploit of the X server gets them your user account and that can cause a lot of mischief and only needs a different local root exploit to get the rest of the way to 0wn1ng your local desktop machine.
Democrat delenda est
I am a bit confused by the submitter's comment about remote X servers. I understand the appeal of remote X clients: I can, e.g., log into a big fast machine and run MATLAB (the X client) there while interacting with the window on my less-powerful laptop (which runs the X server). But what's the point of a remote X server? Why would anyone want to run an X server (software sense of 'server') on a server (hardware sense of 'server')?
If graphics drivers were implemented in the kernel instead of the X server, this problem wouldn't have existed in the first place.
chroot jail the X server.
1. Does this mean you can't login at a graphical interface? I.e. will you have to login at a terminal and then wait for X server to come up?
No. There should be a login X server (running as root or nobody or whatever) to display GDM, then during login this server will exit and launch a new server under your uid. Or something like that.
2. If multiple users login, will each user get their own instance of X server? This seems like overkill...
I think fast user switching already works that way. We don't consider it overkill that each user gets their own instance of Firefox; why is X any different?
I am not sure that this is the right solution. Not running it as root is good, but running it as me - I don't know. I'd rather that the user that runneth the X server is some sort of 'xserver' user - to whose process I connect. That 'xserver' user then has the right to push my screen into VGA mode and all that. Also, this doesn't fix all those other services (that gnome has, for example) that allow my X programs to mount stuff etc. Which is, again, a security risk by itself.
Religion is what happens when nature strikes and groupthink goes wrong.
that wouldn't really work. you still need (without kernel modesetting) access to the graphics hardware.
I am d3matt
X is a large, clutterd and complex system that has no business running as root. It is good to see they finally managed to get away from that implementation, even if it adds a bit more complexity.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Sorry, I forgot to enable the [sarcasm] flag.
Funny how somebody has to write network card drivers for every OS your browser runs on. It's a wonder why nobody has considered putting those drivers in the browser instead.
I just loaded it on my Eee PC and it turns the machine into a kiosk. Very unappealing for anyone who actually wants to use their netbook. Its very flashy and friendly if all you do is check your email and browse the web though.
Mr. Green
Except on any decent Linux distribution, the X server is running inside SELinux and is really not capable of doing much at all.
Technically off-topic, but to use the one of words as is, and another replaced by its analog...
>"The client tells the server what to do."
Imagine if history were revised such that "The SLAVE tells the MASTER what to do.", without reversing the definition of "master" and "servant" (well, unless it's done by Depeche Mode...). The world would be farther along, maybe.
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
Certainly this isn't worse than the current situation. But if my data is still at risk I have a hard time caring much about any "security" advantage.
Without my data the machine is worse than worthless.
Platform advocacy is like choosing a favorite severely developmentally disabled child.
On MacOS X, the X server also runs as the logged-in user. It isn't clear what "nerdyH" means by its last sentence, which doesn't really make a lot of sense. No one who cares about security puts unshielded X Windows sessions on insecure networks, because X Windows data streams between clients (e.g. xterm, Firefox, the Gnome or KDE desktops, or almost anything graphical on any Linux machine) and display servers (the piece that 'serves' a display device to clients) are not encrypted. Remote X Windows sessions are usually kept on private networks or tunneled through SSH. What this protects against is not snooping, but rather against some as-yet-unknown bug in the X server allowing code injection as root. That's a good thing, but it isn't huge. For a system distro, it could be made meaningless by the integrator giving the logged-in user excessive capabilities. To balance my first sentence: Apple provided examples of that in early versions of MacOS X, where file and directory permissions made privilege escalation trivial.
1. Does this mean you can't login at a graphical interface? I.e. will you have to login at a terminal and then wait for X server to come up?
No. There should be a login X server (running as root or nobody or whatever) to display GDM, then during login this server will exit and launch a new server under your uid. Or something like that.
So how do secure logins work? How am I sure whether a graphical login screen is genuine or a spoofed page put up by another user?
Windows requires secure login keys (Control-Alt-Delete) that only the kernel can intercept before showing a login prompt.
Since there was never any reason for the X server and the clients to need to use the same uid, why move the X server from root to the logged in user? It could as well be moved from root to a uid dedicated to the X server. Then you would get another level of separation, at essentially no price. (There is of course a caveat in case you have multiple X servers running at the same time, but that could be solved by allocating a uid per X server).
Does graphics mode switching inside the kernel mean that we can soon expect switching between VTs to work even if the X server is locked up? Or is the keyboard handling still going to prevent that? (Doing the switching from a remote login would work around the keyboard issue).
Do you care about the security of your wireless mouse?
I did this long ago, can't remember what the software package was called now that allowed stateless x11 usage. Essentially a client could disconnect, reconnect, have multiple clients to the same xsession etc. Just like screen.
And it was x11, not VNC.
Change is certain; progress is not obligatory.
because the networks, for which X was designed, did not have "significant" latency
This should be: because the networks for which X was designed did not have "significant" latency.
That loose synchronization is the price, that X-windows designers did not want to pay.
This should be: That loose synchronization is the price that X-windows designers did not want to pay.
security will always require a replication of effort beyond the otherwise economically efficient level. But the cost buys you piece-of-mind, so it's still worth it. And may be partly mitigated by copy-on-write.
Also, there's no reason that the login has to be a terminal. It could just run as nobody.
Can you be Even More Awesome?!
This is a dumb question, and you are dumb for asking it. Try software upping CTRL or ALT before DELETE is pressed.
Support my political activism on Patreon.
I was a video driver developer for Sun for many years. The window system *always* ran as the logged-in user. When I started developing for Linux, I was appalled when I realized that Linux ran the windows server as root.
Here's how we did it at Sun: For every supported video card, there is a device driver. The driver provides basic services such as cursor and color-table management (there are advantages to doing this in the kernel), and additionally allows the user logged in at the console to map in the device registers. This means that the window system doesn't need any special privileges to run.
There are other advantages to having a device driver manage user-level hardware mapping. Not the least of which is that it allowed us to implement full-bore context switching at the device level. The advantages of this are enormous.