
 The Linux Security Circus: On GUI isolation - wglb
http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
======
trotsky
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.

~~~
gaius
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
Similarly, but much less mature, Mirage runs the ocaml RTS directly on top of
Xen: <http://openmirage.org/>

~~~
aristidb
Or, for Haskell on Xen: <http://halvm.org/wiki/>

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

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

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

~~~
tedunangst
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
I think this is what android does, isn't it. Although android doesn't use x.

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

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

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

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

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

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

------
ay
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
Here's some related work from 2005:
[http://www.google.co.uk/search?ie=UTF-8&q=%22A+Nitpicker...](http://www.google.co.uk/search?ie=UTF-8&q=%22A+Nitpickers+guide+to+a+minimal-
complexity+secure+GUI%22)

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

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

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

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

------
jhuni
Insecurity is an inherent part of the desktop metaphor.

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

~~~
tedunangst
Or use the builtin X security extension.

~~~
jojo1
No.

See: [http://theinvisiblethings.blogspot.com/2011/04/linux-
securit...](http://theinvisiblethings.blogspot.com/2011/04/linux-security-
circus-on-gui-isolation.html?showComment=1303633666563#c577377308571446544)

~~~
tedunangst
That comment is long on hype and short on details.

------
jrockway
_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
...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
Thankfully, there's Old Glory for protection against such things:
<http://www.hulu.com/watch/2340/saturday-night-live-old-glory>

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

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

