The Linux Security Circus: On GUI isolation

http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html

by wglb • 15 years ago

126 47 15 years ago

theinvisiblethings.blogspot.com

follower• 15 years ago

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.

there2• 15 years ago

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.

jojo13• 15 years ago

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

rg33• 15 years ago

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.

tshtf3• 15 years ago

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.

jrockway• 15 years ago

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

runningdogx• 15 years ago

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

Groxx• 15 years ago

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

gaius3• 15 years ago

Absolutely!

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

nitrogen• 15 years ago

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.

tzs2• 15 years ago

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.

rst3• 15 years ago

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

ericb• 15 years ago

> One should never run untrusted applications.

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

tedunangst7• 15 years ago

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

rtaycher• 15 years ago

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

tshtf3• 15 years ago

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.

tedunangst7• 15 years ago

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

tshtf3• 15 years ago

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.

rst3• 15 years ago

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

rst3• 15 years ago

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

sciurus• 15 years ago

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

rg33• 15 years ago

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

rg33• 15 years ago

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.

jojo13• 15 years ago

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

tedunangst7• 15 years ago

Or use the builtin X security extension.

jojo13• 15 years ago

No.

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

doki_pen• 15 years ago

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.

recampbell• 15 years ago

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.

viraptor• 15 years ago

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

tzs2• 15 years ago

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

trotsky2• 15 years ago

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.

rwmj• 15 years ago

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

gaius3• 15 years ago

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?

jamii• 15 years ago

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

jhuni• 15 years ago

Insecurity is an inherent part of the desktop metaphor.

cygwin98• 15 years ago

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.

trotsky2• 15 years ago

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.

ay• 15 years ago

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.

nominolo• 15 years ago

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

The Linux Security Circus: On GUI isolation

Related Stories