Qubes seems to be YASTVOS (Yet Another Security Through Virtualization OS). While I'm not going to disagree that Xen vms represent a smaller attack surface than most current installations, that doesn't mean there won't be bugs. If you shift everyone to a solution like this, guaranteed people will be breaking out of it. VMware has had a number of vm escapes.
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.
The state-of-the-art on attack surfaces and VMs right now is JRockit Virtual Edition, which runs the JVM directly on the hypervisor, no OS in the middle. Which makes all kinds of sense really - what's the point of running a VM inside a VM?
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.
Now, for the best, start another terminal window, and switch to root (e.g. using su, or sudo). Notice how the xinput running as user is able to sniff all your keystrokes, including root password (for su), and then all the keystrokes you enter in your root session. Start some GUI app as root, or as different user, again notice how your xinput can sniff all the keystrokes you enter to this other app!
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.
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...
I believe the point is that users want to run firefox and openoffice at the same time, but they don't trust firefox to not have remotely exploitable bugs. So they run firefox as a different user, assuming that if it can't read their secret files or the memory of openoffice, they're safe. They are wrong.
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()).
Maybe I misunderstood this article. It seems to me there is a security issue in X Server, which gives out keyboard input info to all running X apps. That's fine. If that's X Server, just fix it then everyone will be happy. Why introduces all the Xen/VM stuffs into this problem. It is like you have a mosquito flying around, but you choose to kill it using a nuclear bomb.
I'm sure that they didn't set out to solve just this one problem. Rather there are a whole slew of problems that per process vm sandboxing could solve (and a number that it could create). They're just interested in advertising their newly beta OS, and they are pointing out an issue they see in the X architecture that their solution happens to mitigate.
xterm has a secure keyboard option from its menu (control+click) that is supposed to prevent other applications from being able to receive X11 events related to input.
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.
Thanks for pointing out the "Secure Keyboard" option. Make sure to test it before relying on it, though. I just tested in my system and it does not prevent "xinput test" from receiving the key presses, even when typing the "su" password.
In the OS X GUI, the Authorization Services API handles this. The SecurityAgent process, running as a different uid (_securityagent), controls the window that the user enters her password to escalate privileges.
So, trying again... here are the caveats on -X, from the man page on the current version:
-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.
So, it's not documented as being proof against hostile parties with root at the remote end; in fact, it's documented as being vulnerable...
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.
[deleted former mummery after five-minute fact-check]
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"...
'-X' is supposedly the safe alternative to '-Y'. However, as a Cygwin/X maintainer says "this is widely considered to be not useful, because the Security extension uses an arbitrary and limited access control policy, which results in a lot of applications not working correctly and what is really a false sense of security"
The X server architecture, designed long time ago by some happy hippies who just thought all the people are good and non-malicious
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 argument is nonsense. Any program you run can exec other programs and read files from your home directory. You can't simply run any program you feel like running. If it's not a well known and trusted program, then you'll need to look at the source.
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.
I don't think it's nonsense. I'm quite surprised that (say) my calculator app could control my password manager. My password manager encrypts file storage, and automatically locks itself after usage, but is likely vulnerable to this attack.
Even if you trust the programs you run, they can have their own unintended vulnerabilities.
> Do people run root GUIs as a client? That seems silly to me.
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?