Moblin Will Run X Server As Logged-In User, Not Root 205
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."
IMHO (Score:2)
This is something that is long overdue.
Re: (Score:2)
Ya think? X is older than I am.
Can someone spare me reading the article and let me know if DRI is still possible without root?
Re:IMHO (Score:5, Informative)
> Can someone spare me reading the article and let me know if DRI is still possible without root?
Yup, this whole thing rests on the new kernel modesetting. That was the last thing that required root to be able to directly frob bits on the video card. DRI also goes into the kernel as it should. The kernel is supposed to own all of the hardware and expose safe APIs for user apps to access it. For historical reasons video has been the exception to that rule. No longer.
Re: (Score:3, Interesting)
Re:IMHO (Score:5, Informative)
> Sounds like Windows NT 3.5, wonder if it will get moved back into kernel
> space for performance reasons just like NT4 moved video back into kernel space.
Not the same thing. The video hardware belongs in the kernel in exactly the same way as sound, mass storage and the keyboard/mouse do. *NIX and Windows are now alike in that and it is good.
What Windows did was bring most of the next layer up the chain into kernel space. This would be more like putting the whole X server and bits of GTK and/or Qt into the kernel, not just running it as root. Yes it improved performance some, but the security implications are horrific.
Re: (Score:2)
Sounds like Windows NT 3.5, wonder if it will get moved back into kernel space for performance reasons just like NT4 moved video back into kernel space.
No, NT4 moved hardware-independent stuff like the GDI and the window system into kernel space, where it doesn't really belong. The hardware-specific video card drivers were always in kernel space, where they do belong.
In X, hardware-independent stuff like window managers and widget sets ran in user space, where they do belong, while the hardware-specific video card drivers also ran in user space, where they don't really belong.
Pick your poison.
Re:IMHO (Score:4, Interesting)
Er, the same way USB was for years? Actually, DRI, too. The driver exposes a pseudo-device in /dev/, which actually is a socket-like, high-throughput mmap wrapper and the X server opens it. Given appropriate file permissions and group membership, this can be done from a user account.
Re: (Score:3, Insightful)
Yes, DRI access is done through /dev/dri* and works correctly.
Confused article. (Score:5, Insightful)
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.
X Hosting? (Score:4, Informative)
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.
Re: (Score:3, Insightful)
> I'm not sure I grasp the concept of X Hosting, and how this non-SUID server would help
> that.
It wouldn't. The author of the article hasn't the foggiest notion of how X works (well, he does have a foggy notion, but it's wrong). The machine(s) running the client(s) run only the client code and run it as the user.
Re:X Hosting? (Score:4, Insightful)
Re: (Score:3, Informative)
Ive used X over network connections and I know this to be incorrect, at least over a ethernet. THere are also solutions avialable for the problems you mention, or which can be addressed. There are various products that will compress the X data stream so that it uses less bandwidth and can perform quite acceptably. Such as NX. There was for a while a provide called xmove which was an X proxy to which your X clients would connect, you can send xmove command to redirect the display of the X client between diff
Re: (Score:2)
Both processes — one running two stories below and one thousands miles away — ran smoothly, the seconds-hands were moving at the same time, and it would've been easy to mistake one for the other, had it not been for the 3-hour difference between them...
Not that it matters, since you still have to go through the process of converting a complicated graphical representation system to Hour:Minute:Second, rather than just having a decoded display.
Punctuation Police (Re:X Hosting?) (Score:2)
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.
Re: (Score:2)
> This seems to be entirely a local security gain for users who will be interacting with local graphics hardware.
correct !!!
Correct me if im wrong (Score:2, Insightful)
But running apps remotely and having them display on a local X server _NEVER_ required root access of any kind on the remote server....
Re:Correct me if im wrong (Score:5, Informative)
The X server is the program on the local machine that displays the pixels.
The program you run on some other system via the net is the client, even if the thing it's running on is called a server.
The X server traditionally runs as root. You are likely unaware of this because it's started automatically as part of the init process.
The X server running as root is independent of whether the X client is running as root.
Re: (Score:2)
"The X server traditionally runs as root. You are likely unaware of this because it's started automatically as part of the init process." On many systems it's started by init, but that's not the reason it has root, it has root because the X-binary has setuid bits set.
Re: (Score:2)
Actually on any modern desktop/workstation running X it's possible to remove setuid bit from X server, and everything will continue working because X server is started by display manager (usually gdm) running as root. Setuid /usr/bin/Xorg exists entirely for convenience of the users who log in at the console, then run xinit (all five of them).
Re: (Score:2)
> But running apps remotely and having them display on a local X server _NEVER_ required root access of any kind on the remote server....
entirely correct, the X server is the component talking to the video card.
Poor understanding of X (Score:5, Informative)
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?
Re:Poor understanding of X (Score:5, Informative)
How is this backwards?
It's only backwards in human thought, because people have the ingrained presupposition that the server is the Big Machine In Another Room, and the client is the Little Machine On Your Desk.
Re: (Score:2)
Re: (Score:2)
For the way that X works it's correct.
But, X is the wrong way around, you should have a client running on the local machine that connects to the remote machine and provides it with a remote display. Like telnet or ssh or VNC or MS Remote desktop or Citrix seamless windows or "ssh -X"!
In fact X is that ONLY one that puts the server next to the display with the security implications inherent in that.
Re: (Score:2)
Yes I get it, the TCP/IP connection connects to the machine with the screen, so the machine with the screen is the server in X.
BUT, X is the wrong way round. NOTHING else connects a display with a process that way and even with X the first connection is FROM the display TO the CPU server and tell the CPU where to find the X server. So every remote X connection actually consists of two connects one from the DISPLAY TO the CPU (usually cached and often an XDM connection but it can be a telnet) the second i
Re: (Score:2)
All is clear if we understand what it is serving. X is serving the display to your eyes. Web-server is serving pages to your web-client/browser.
X is serving the display and keyboard (and your eyes) to your firefox and xterm.
Stupid (Score:4, Informative)
> 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.
Re: (Score:2)
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.
Yeah, the submitter is clearly clueless as is timothy since he couldn't notice such a glaring error.
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
Which is far less dangerous than them getting root access.
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.
Which basically makes it harder for someone to get root access since they have to find another exploit to gain it.
Re: (Score:3, Insightful)
> Yeah, the submitter is clearly clueless as is timothy since he couldn't notice such a glaring error.
Well the Slashdot editors went to the Grey Side (Mac) a decade ago so what the hell would they know about X. The /. servers are still *NIX so they know and care about that side a bit.
> Which basically makes it harder for someone to get root access since they have to find another exploit to gain it.
Sure, this move is a win for security because X was big complicated and running as root, but not cause f
Re: (Score:2)
SELinux (Score:2)
Except on any decent Linux distribution, the X server is running inside SELinux and is really not capable of doing much at all.
Remote X servers? (Score:4, Informative)
Re: (Score:2)
You don't need X for Matlab. The interface isn't that good.
Re: (Score:2)
You don't need X for Matlab. The interface isn't that good.
It's for plots that having X is useful.
Re: (Score:2)
Re: (Score:2)
Hmm... What that lacks is the ability to interact with the plots (zoom in, etc), which I like sometimes... but on the plus side, as you said the overhead is lower, and also 'screen' will work (whereas the equivalent for X clients, 'xmove,' doesn't play nice with xauth, and anyway is rarely installed on servers to begin with).
A third method that a friend of mine uses (for very big jobs) is to have the MATLAB script generate emails; he just runs it with nohup and logs out.
Re: (Score:2)
It depends on what you're doing with matlab. If you're just futzing around with things, then you're not writing scripts, you're using the command line and checking what the equations look like every three or four lines of code. I'd say this covers at least 60% of undergrad student usage of matlab, which is likely the most common version, since the student version comes in at under $100 and the real version could be up in the thousands depending on what toolboxes you get. Otherwise octave would be a lot m
Re: (Score:2)
I doubt I know enough to answer your question, but your question itself confuses me. You understand why someone would want to run "remote X clients", but you don't understand why someone would want to run "remote X servers". If you don't have a server, then who is the client connecting to?
Re:Remote X servers? (Score:4, Informative)
The "X server" runs on the machine with the keyboard, mouse, and display. An "X client" is a program (e.g., xterm) that connects to an "X server" to which it sends drawing commands and from which it receives mouse and keyboard events. In the "writing network software sense," these names make sense, because it is the "X server" that sits and listens on a port, and the "X clients" that connect to it. What makes this confusing is that in practice an "X server" will usually run on a user's machine (which you would normally call a 'client') and an "X client" will run on a big machine elsewhere (which you would normally call a 'server'). The problem comes from using the words "client" and "server" to describe both programs and machines; basically, our jargon sucks.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Sorry, feeling particularly bitter and twisted this evening
(* or get appointed CTO)
Re: (Score:2)
A remote X-server is what runs the video wall. I can run the client program on my workstation and have it display on the wall.
Now, I just need to install the video wall in my underground lair.
Re:Remote X servers? (Score:4, Informative)
It's not just the submitter. Apparently the writer of the blog post themselves don't even understand X all that well.
Re:Remote X servers? (Score:5, Insightful)
Re: (Score:2)
Maybe we need to throw out all the words and replace them with alternatives like "listener" and "caller" for the programs and... "big machine" and "little machine" for the computers? :-)
So what happens when you have a horribly overpowered gaming desktop and one of those dinky embedded "home NAS" things? :-p
Re: (Score:2)
Graphics drivers (Score:5, Insightful)
If graphics drivers were implemented in the kernel instead of the X server, this problem wouldn't have existed in the first place.
Re:Graphics drivers (Score:4, Interesting)
Yes, it's interesting that KGI was rejected 10 years ago, but now we have KMS. What has changed?
Re: (Score:2)
KGI replaces X, KMS only implements the hardware-specific parts in the kernel, while keeping the entire Xorg userspace (the real "graphics" parts) in userspace.
Re: (Score:3, Insightful)
What has changed?
The fanatics have become more reasonable?
Re: (Score:2)
Also, I think KGI wanted to push a lot more into kernel space that we have now, even with kernel mode-setting, though my aging memory may well fail me..
Re: (Score:3, Funny)
Linus isn't perfect
I met Linus in person a while back and asked him about this. He disagrees with you.
Since he's perfect, I kinda have to go with him on this one.
Re: (Score:2)
Well, that certainly begs the question; How do you know he's telling the truth?
Re: (Score:2)
s/been/been pretty good/
Proof-reading ability falls off with increasing blood alcohol levels, sadly
Re: (Score:2)
Re:Graphics drivers (Score:5, Insightful)
Re: (Score:3, Insightful)
If graphics drivers were implemented in the kernel instead of X, you would have to write new drivers for every kernel you want to run X on.
Re: (Score:3, Insightful)
We have that situation for all other drivers and somehow we survived. Also, it's common for vendors to write a single BSD-licensed driver and then port it to multiple OSes, sharing most of the code.
Network drivers (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Is this right ? (Score:5, Interesting)
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.
Re: (Score:2)
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.
So if you have multiple users on the same machine running X, they can stomp on each other (by virtue of all interacting with the same "xserver user") ?
Re: (Score:2)
I guess we all need xusername users so everyone has a seperate user to run X. ;-)
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
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.
As another poster mentioned, this makes multi-user X a bit more difficult. What's the issue of having your user ID doing all this? If you're allowed to log into the console, then you're presumably allowed to run X (or not; you can still lock down the machine so particular users can't run X or access the graphics hardware). If you can run X, you can talk to the graphics hardware. Note that this doesn't give you carte-blanche to fiddle with the graphics card's registers to try to make the machine crash: y
I don't know... (Score:3, Insightful)
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.
Re: (Score:3, Insightful)
What's the issue of having your user ID doing all this?
A remote hole in a process run as 'nobody' allows some log files to be trashed, maybe.
A remote hole in a process run as me allows all of my data to be destroyed.
Been waiting for this (Score:2)
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.
Re: (Score:2)
It looks like they have done this by pushing the hard parts into the kernel. I'm not sure this doesn't make security worse.
Have you used Moblin? (Score:5, Informative)
Re:Have you used Moblin? (Score:5, Insightful)
Its very flashy and friendly if all you do is check your email and browse the web though.
Almost like that was the entire point of the distro in the first place!
Re: (Score:2)
I've not used it, but the following is my understanding based on the website:
Moblin is designed to support social networking, media viweing/playing, and web browsing.
Social networking integration is a main point. Update your flicker status from a drop-down panel of the main toolbar.
For media viewing the system intends to allow to to browse local and remote media, with integration with services like flicker and last.fm.
I did not see any IM integration in the short introduction video, although it is a fairly
Re: (Score:2)
Since you have tried it, can you answer a couple of questions.
1 - can you open a shell/terminal window?
2 - can you create custom application launchers
If so, how is it so unappealing. Perhaps you just need to customize it a little to make your needs more accessable. If not, then you have saved me the effort of giving it a try.
Not exactly innovative. (Score:2)
Re: (Score:2)
Re: (Score:2)
That isn't really a valid comparison, since Mac OS X doesn't run X natively. You can run an X server as an application, but that X server doesn't drive any hardware, it is just yet another application using the Mac OS X graphics system (which is otherwise incompatible with all other operating systems known to me). It's just like running an X server on Windows or Xnest on something else (I think Xnest is able to make a few shortcuts because it happens
Why not take it one step further? (Score:3, Insightful)
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).
Re:One of the shortcommings in security (Score:5, Informative)
I don't know how they've done it, but I know this is a good thing.
They've done it by removing the responsibility of X talking directly to the graphics hardware by implementing Kernel Mode Switching for graphics drivers (among other much needed overhauls to the Linux graphics stack). Thus X can now access what it needs at the logged-in users' level and doesn't need root.
Re: (Score:2)
I don't know how they've done it, but I know this is a good thing.
They've done it by removing the responsibility of X talking directly to the graphics hardware by implementing Kernel Mode Switching for graphics drivers (among other much needed overhauls to the Linux graphics stack). Thus X can now access what it needs at the logged-in users' level and doesn't need root.
I could always do startx as a user. Was I missing out on some hardware features by doing that?
Re: (Score:2)
No, X-Windows was installed as SUID root. SUID is a file flag in the standard unix permision system that indicates that when anyone (who has permission) executes a file, the user ID for the process is set to that of the file owner, in this case root. So, basically you have been running the X server as root and you didn't know it.
Setting the SUID flag of root-owned files is strongly frowned upon. If you are doing this you are basically stating that you trust that application as much as you trust the kernel,
Re:One of the shortcommings in security (Score:5, Informative)
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.
I think what is basically boils down to, is that instead of X talking to the hardware directly it now talks to a file under /dev/ just like everything else.
Re: (Score:2)
Yep, that's it I guess, changes to hardware management. I have been running Xvnc X server for years as a normal user since it doesn't need to talk to the hardware.
Re: (Score:3, Insightful)
How big of a security problem was this? I haven't seen a linux system with open ports for X in 10 years. Anyone who wants to use remote X just uses ssh -X, it's easier to set up than xhost anyway.
Re: (Score:2)
Every X API allowed the user to insert possibly bad data into the Xserver, possibly exploiting the suid root bit by forcing a buffer overflow/underrun etc.
Imagine how many X API's there are, and all of them result with user data ending up in root memory space. Local root exploits could be anywhere in any X library.
Re: (Score:3, Informative)
But yes, true -- any exploitable flaw in the X server itself (or any of the extensions compiled into or loaded dynamically by the server) could result in root access.
Re: (Score:2)
So the kind of attack I'm envisioning is say, I'm a malicious site operator and you ssh -X into my system. You start an X client program that I've hidden an exploit in. That X client exploits your X server giving me root on your machine.
It wouldn't work the other way would it? If I ssh into your machine and run an X client, I can't root your machine.
Re: (Score:2)
Huge. XFree86, for example, is over 2 million lines of code. Given that there is an average of one security bug per 1,000 lines of code (according to the DoD), this means that there are likely over 2,000 security bugs in the X server. That's 2,000 privilege escalation attack vectors that a local user could use to gain root privileges by smashing on the X server in the right way.... If the X server runs as the local user, then all of those bugs become mostly moot (crash risk notwithstanding).
Re:One of the shortcommings in security (Score:4, Interesting)
Re: (Score:2)
Re: (Score:2)
Re:frost nixon (Score:5, Insightful)
Re:frost nixon (Score:5, Insightful)
Re:Two questions: (Score:4, Insightful)
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?
Re: (Score:2)
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.
Re: (Score:2)