Oh noes!
I just found the following security vulnerability: someone could smash their way into my house, and then threaten to hit me with a large pipe unless I gave them my bank information. Damn those hippie system designers that didn't include an armored work area!!!
This is not the problem it's made out to be:
1. An application running as a different user can only connect to the X server if it has access to the .Xauthority file. This means there's no risk of having another user connect to your X session and sniff keystrokes, unless you explicitly chmod o+r ~/.Xauthority.
2. One should never run untrusted applications.
Now, I will grant that better GUI process isolation and/or granular X permissions would be useful, in that it would lay the groundwork for a safe way of allowing an untrusted remote (or local) process to display a GUI on the local X screen. I've also always wished window managers would highlight windows from a different user with a red border, mostly so I could tell which file browser window I'd started with sudo.
the thing you are referring to on os x is similar, with a system-wide capability. when you enter passwords for keychain and similar things, these have secure input enabled by default. i think it's up to the application to enable it, but when it's enabled for a field, no other application can intercept those events.
So, what applications do you trust, to never, under any circumstances, get subverted by third parties? I don't know about you, but I personally find it hard to have that level of trust in anything that's written in C, and talks to the network --- but without any of those, these days, you're left with a pretty spartan and uncomfortable environment.
Besides which, allowing any app to read any other's keystrokes, without special arrangement is a pretty clear violation of the principle of least privilege. It may have been appropriate for research environments twenty years ago ("hey, the window manager can be just another app! isn't that neat?"), but Rutkowska's quite right to say that it's not good design for the world that we're living in now...
Security through omniscience? Is that any kind of answer? This is a whole that can be plugged.
This problem has in fact been solved by the X security extension. The problem is that nobody tests their programs as untrusted clients. GTK, for instance, will more or less immediately abort because its error checking consists of assert(trusted_only_operation()).
Edit: Ignore this, I was incorrect.
Unfortunately, the documentation on -X and -Y is awfully confusing. On a casual read, it looks like -Y is less safe, since practically the only thing the docs for -Y say is that forwarded connections are "not subjected to X11 SECURITY extension controls"...
Do people run root GUIs as a client? That seems silly to me. I don't have one single GUI program that I run as root unless I'm troubleshooting a permissions issue.
Even if you trust the programs you run, they can have their own unintended vulnerabilities.
-X Enables X11 forwarding. This can also be specified on a per-host
basis in a configuration file.
X11 forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
user's X authorization database) can access the local X11 display
through the forwarded connection. An attacker may then be able
to perform activities such as keystroke monitoring.
[1] http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion...
The other problem is these OS's often don't seem to get very far. Seems like Qubes is launching beta 1. It's the kind of thing that one would expect needing a significant time to shake out.
Which isn't to say I wouldn't like to run a nicely implemented example of the concept. It certainly has the possibility of raising the bar significantly. Of course, it seems like no matter how far windows raises the bar people still keep on jumping it easily.
For this reason, X11 forwarding is subjected to X11
SECURITY extension restrictions by default. Please
refer to the ssh -Y option and the ForwardX11Trusted
directive in ssh_config(5) for more information.http://selinuxproject.org/page/SVirt
This is now a standard feature in Fedora (since Fedora 11):
http://fedoraproject.org/wiki/Features/SVirt_Mandatory_Acces...
No, but that's where escalation comes in. You go to a page which uses javascript to take over your browser. Now your browser can capture and send back your shell password captured from the terminal window.
http://wayland.freedesktop.org/architecture.html
The document explains that the Wayland compositor, when receiving an input event coming from the kernel input drivers, decides which window has to receive the event and sends it to the application.
If it really works that way, native Wayland clients could be isolated from other clients and they would not receive input events directed to another client. But, in practice, the Wayland server could have facilities for clients to register and receive all the events, so I'm not sure how all of this would turn out.
The bad press X gets is like banning HTTP because someone broke into your webserver once...
When you need to su or sudo, do you switch away from X to a separate virtual console, or do you just do it in an xterm (or equivalent)?
How about when you want to ssh to a server and do something, possibly including su or sudo on the server. Again, do you do that from an xterm or equivalent on your desktop machine, or do you switch out to a separate virtual console for all your ssh activity?
http://qubes-os.org/Screenshots.html shows two browser windows, which is great. Now, what I do not see is the interaction from the HCI side.
Two browser windows - "secure" and "non-secure" are quite a pain to work with if one has to copy/paste links manually.