The Linux Security Circus: On GUI isolation | Hacker News Reader

The Linux Security Circus: On GUI isolation

theinvisiblethings.blogspot.com

126 pointswglb47 comments

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.

For KVM, we've implement SVirt. We don't trust the main userspace (qemu-kvm) process, and assume that it has been subverted by the guest. We contain it using SELinux rules.

http://selinuxproject.org/page/SVirt

This is now a standard feature in Fedora (since Fedora 11):

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

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?

Similarly, but much less mature, Mirage runs the ocaml RTS directly on top of Xen: http://openmirage.org/

I've heard of Mirage and am looking forward to it being ready for prime-time :-)

Or, for Haskell on Xen: http://halvm.org/wiki/

Does anybody know by any chance how does the Wayland server work in this regard?

Replying to myself. I just read the architecture document for Wayland, which can be found at:

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.

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.

You can't always avoid untrusted applications if you use the net, unless you make sure to only use client software that has no exploitable bugs that can lead to local code execution.

"One should never run untrusted applications."

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...

> One should never run untrusted applications.

Security through omniscience? Is that any kind of answer? This is a whole that can be plugged.

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()).

I think this is what android does, isn't it. Although android doesn't use x.

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.

I seem to recall the "Secure Keyboard Entry" option (in the application menu) in Terminal on OS X is supposed to stop the su/sudo problem on OS X at least for terminals.

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.

xinput is still able to read all keys when xterm's secure keyboard is enabled.

right, because it's not operating on x11 events, it's just directly reading xinput data. there's not much xterm can do when the underlying server is giving away all of the raw input data.

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.

I'd speculate that the browser is the biggest firehose through which the junk can come in.

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.

Here's some related work from 2005: http://www.google.co.uk/search?ie=UTF-8&q=%22A+Nitpicker...

ssh with X11 forwarding (-X option) had this same problem. A privileged malicious user on the host you were ssh'ed into might be able to monitor the keystrokes of your whole X session.

Note that hasn't been true for years and years. -Y and -X are different.

That's why I mentioned the -X option... -Y handles the problem the correct way and doesn't have the same issues.

Edit: Ignore this, I was incorrect.

You have that backwards.

[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"...

You were apparently more right the first time. -X establishes an untrusted connection, subject to limitations. -Y says "trust me, no limits". -Y is the less safe option.

So, trying again... here are the caveats on -X, from the man page on the current version[1]:

     -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...

[1] http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion...

That's why the next paragraph exists.

    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.

'-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"

http://cygwin.com/ml/cygwin-xfree/2008-11/msg00154.html

Insecurity is an inherent part of the desktop metaphor.

Currently the only secure way is to start a second X screen with another uid.

Or use the builtin X security extension.

No.

See: http://theinvisiblethings.blogspot.com/2011/04/linux-securit...

That comment is long on hype and short on details.

The X server architecture, designed long time ago by some happy hippies who just thought all the people are good and non-malicious

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!!!

...a major difference being there are not robots yet that can go around breaking into people's less-secure houses and torturing residents for information, all in an automated fashion.

Thankfully, there's Old Glory for protection against such things: http://www.hulu.com/watch/2340/saturday-night-live-old-glory

Old Glory is no protection at all - it's just there to compensate your loss in the even of a robotastrophe. Insurance.

Absolutely!

The bad press X gets is like banning HTTP because someone broke into your webserver once...

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?

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.

> 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?

Reply on news.ycombinator.com