
The Linux Security Circus: On GUI isolation - simonbrown
http://theinvisiblethings.blogspot.fr/2011/04/linux-security-circus-on-gui-isolation.html
======
zobzu
SELinux has xorg hooks [1] to isolate the gui, actually... yes that means with
SELinux you can control which window can talk to which, what clipboard can be
used where, by what window, etc.

not that it makes the xorg code better in any way, but, when you're going to
say the world is ignorant and you know it all, at least get your stuff right.

Thats why people "hate" you as you describe in this post. Having an aggressive
style doesn't make you more accurate. It just makes you annoying.

[1]
[http://www.nsa.gov/research/_files/selinux/papers/xorg07-pap...](http://www.nsa.gov/research/_files/selinux/papers/xorg07-paper.pdf)

~~~
long
She is aware of this but has a bone to pick with the particular way that SE
Linux secures the GUI: [http://theinvisiblethings.blogspot.com/2011/04/linux-
securit...](http://theinvisiblethings.blogspot.com/2011/04/linux-security-
circus-on-gui-isolation.html?showComment=1303575708573#c8629263254767793603)

I agree, though, that the style is overly aggressive.

~~~
ris
I particularly disagree with her assertion that Xen is a more trustworthy
place for security over the "big, bloated linux kernel". I would argue that
the (perhaps smaller) Xen code has seen far less security scrutiny than the
kernel and has a far less pronounced culture of security.

~~~
zurn
Linux doesn't have a good culture of security. Local root bugs are dime a
dozen. Security fixes in the kernel are not flagged as such. There's no
systematic effort to stop the most common types of security bug (memory bugs
in some driver ioctl handler). Linus doesn't have much patience for or
interest in security improvements - look at
[http://article.gmane.org/gmane.linux.kernel/706950](http://article.gmane.org/gmane.linux.kernel/706950)
\- Etc etc.

~~~
ris
Before submitting, I debated whether to put a disclaimer line in - "not that
the kernel has the worlds best security record", but I thought - nah nobody's
going to use this as an opportunity to jump in & grind their "kernel security"
axe. What a fool am I.

I however think the relative silence around Xen security is far more of a
worry. That was my point.

------
schoen
I agree with the concern and appreciate the solution that Qubes offers.

It might be worth pointing out that some of the "hippies" also became
concerned with this and implemented their own partial solution within the X
framework decades ago -- the "secure keyboard" feature. You can see it in
action: run an xterm, Ctrl-Left Click in the window, and choose "Secure
Keyboard" from the menu. Now all X11 keyboard events are sent exclusively to
that xterm, not to any other X application (even if the other application has
focus). Caution: for these purposes the window manager is also an
"application", so you won't even be able to Alt-Tab to switch applications
while the secure keyboard mode is active!

The X11 developers assumed that you would use the Secure Keyboard feature
while typing important passwords. There's a pretty elaborate discussion of
this in the man page for xterm(1).

There, the threat that they're most focused on is remote display access from
applications on other hosts, rather than malicious software potentially
running on the local host. For example, the authors of xterm fear that you'll
be using machines foo and bar in the same computer lab, and run "xhost foo" on
bar, and then an attacker will rsh into foo and log in to their account there
and then run "DISPLAY=bar:0 keyboard_sniffer" from their account on foo,
whereupon the X server on bar will conclude that the remote client request
from foo is perfectly legitimate because you told it to accept all X11
connections originating from foo.

Of course the secure keyboard feature only partially mitigates one aspect of
this threat, while Qubes offers a much more thoroughgoing and useful
mitigation to a larger range of things. (I might also mention ptrace, where
recent Linux distributions have activated a kernel policy which forbids, by
default, having a non-root process start to ptrace another running process
that isn't its child. I believe this was in response to malware grabbing
private keys from programs like ssh-agent via the ptrace interface. Oops. It
does also mean that you can't strace -p or gdb attach something that's already
running, unless you become root and change the policy.)

In general, the idea of protecting against software that's running locally as
the same user is something of a novelty on most desktop OSes.

[https://en.wikipedia.org/wiki/Discretionary_access_control](https://en.wikipedia.org/wiki/Discretionary_access_control)

~~~
Someone
We also have
[http://www.cs.dartmouth.edu/~doug/IX/](http://www.cs.dartmouth.edu/~doug/IX/),
in particular _" Multilevel Windows on a Single-Level Terminal"_
([http://www.cs.dartmouth.edu/~doug/IX/163f.ps](http://www.cs.dartmouth.edu/~doug/IX/163f.ps)):

 _" The workings of mux, a windowed-terminal handler, that can run differently
classified sessions in different windows."_

[google search tip for historians/computer archeologists who don't want to
find SE-Linux when searching for Unix history: enter "before 1/1/{years ago}
as a custom time range]

------
eliteraspberrie
_BTW, Windows is the only one mainstream OS I 'm aware of, that actually
attempts to implement some form of GUI-level isolation, starting from Windows
Vista._

Is GetAsyncKeyState still available in Windows Vista? I'm guessing it is, and
processes can still read each others' keystrokes without problem. The MSDN
documentation doesn't mention it being deprecated.
[http://msdn.microsoft.com/en-
us/library/windows/desktop/ms64...](http://msdn.microsoft.com/en-
us/library/windows/desktop/ms646293\(v=vs.85\).aspx)

(By the way this article is from 2011. It would be interesting to read an
update.)

~~~
ef47d35620c1
Yes. Here's a Windows keystroke logger (with source code) that uses
GetAsyncKeyState. I wrote this years ago to show an IT auditor that a
restricted user could run a keystroke logger (he was adamant that was not
possible). It works on Windows XP to Windows 8.

[http://16s.us/software/16k/](http://16s.us/software/16k/)

~~~
CyberShadow
GetAsyncKeyState will not reflect input that is sent to an elevated window.
So, it does not break UIPI.

------
bm98
The very first comment below the article (correctly) contradicts the author's
claims about SELINUX sandbox. The author acknowledges the comment, and
criticizes the SELINUX implementation, but does not dispute the fact that
SELINUX sandbox ("sandbox -X xterm" in RHEL/CentOS/Fedora/SL) does in fact
defeat the keystroke logger attack described in the article.

~~~
reidrac
I would be nice if the article was amended to acknowledge the fact that a
SELinux sandbox actually avoids "the problem".

I'm being confused with the "you will likely need to install it first: yum
install xorg-x11-apps"; which means you need extra privileges before
implementing the attack "as normal user!".

I guess the problem is not local access but a malicious app perhaps, but then
it doesn't matter too much anyway because there are other ways of compromising
the system.

~~~
koios
The yum install xorg-x11-apps bit is so you can use the xinput tool as a
demonstration of the problem. Fedora doesn't have it by default apparently so
you need to install it.

A malicious app could just directly use the X protocol, no need to call this
app, so unfortunately no additional privileges are needed.

------
ams6110
In the 1990s I worked at an investment bank, all the developers had X
terminals (these were workstations that just ran X servers, they did not have
any other local compute or storage resources). I discovered one day that I
could run a program and direct the display to any X terminal in the network.
There were some screensaver-type programs that would make everything on your
screen a mirror image, or appear to melt down and run off the bottom of the
screen. It made for some fun pranks.

~~~
SixSigma
That is by design and is the default, it is specifically mentioned as an issue
in the first paragraph on the manpage
[http://www.x.org/archive/X11R6.8.1/doc/Xsecurity.7.html](http://www.x.org/archive/X11R6.8.1/doc/Xsecurity.7.html)

------
simondedalus
i've been saying for awhile now (to anyone bored enough to listen) that qubes
style isolation is the only safe idea on offer these days. i just wish qubes
were usable.

i'm fairly sure that 10 years from now people are going to be citing joanna
rutkowska articles with regularity. her flatfooted denial that security is
possible without isolation is the only sane perspective.

the point is that starting from full isolation and straining to get things to
talk to each other in the hope of achieving productivity makes sense. starting
from full interactivity and straining to isolate but just when it's necessary
"for security" is a battle we will all eventually lose, and we should know it
already.

~~~
anaphor
Doesn't djb espouse a similar viewpoint wrt sandboxing? Not to say she doesn't
have any original ideas for how to achieve it, but it's hardly a novel
concept.

~~~
simondedalus
yes.

i'm not saying the concept is novel, i'm saying that it's the only viable
option for the systems of today. related to that, i think the qubes approach
will be adopted eventually (and that articles of hers, specifically, that i've
read will likely come into fashion, despite the--dare i say it--borderline
sexist reaction many on hn seem to have to "her tone").

regarding outright original thought, i'm sure both she and he are guilty of
it. probably you and i as well; it's easier than a lot of people think. the
world is large and complex, and really most of the "oh my god i can't believe
[person] thought of [amazing idea]!" really ought to be marveling at the fact
that [person] implemented [amazing idea] as a practical tool.

sure, we rehash over and over in our thought, but the world of ideas is so
specialized that given even a few months of serious study, novelty is not
particularly impressive.

~~~
jnbiche
Oh come on, sexist? Did you read her exchanges in the comments? She's just
another Torvalds, with respective to her attitude and people skills. Why
shouldn't we call her on it, if we criticize Linus?

She may be a brilliant researcher, but being aggressive and insulting toward
others will only hinder her attempts to redefine the security landscape.

~~~
simondedalus
if someone said to linus

"given that kernels are your research project, i expected that you'd already
tested whatever you're talking about on wayland and contacted its developers
about security holes,"

and he replied curtly, i don't think anyone on hacker news would be "calling
him out." the idea that her tone is "too aggressive" is highly suspect. it is
not unusual to express ideas as if you believe them, nor to conduct yourself
as if your blog posts needn't be written in the tone of My-First-Job-Interview
or Visiting-My-Conservative-Grandmother-In-The-Hospital.

~~~
vacri
You would be wrong. Torvalds gets some regular hate-machine action here every
couple of months. Someone finds a frustrated mailing list message of his and
posts it out of context, and half of the resulting comments are about how
Torvalds really shouldn't be a project lead with an attitude like that, or how
he's damaging open source, or all sorts of pronouncements on his behaviour.

------
sandGorgon
Can someone (who is more familiar than me on this topic) comment on whether
this is a by-product of Xorg running with root privileges.

The systemd-logind work on Fedora [1] is attempting to run Xorg without root
rights (and Wayland/Weston[2] in the future) and I'm wondering if that is a
much more effective fix than all this sandboxing ?

[1]
[https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights](https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights)

[2]
[https://plus.google.com/+DavidHerrmann/posts/ggK1tStCvJH](https://plus.google.com/+DavidHerrmann/posts/ggK1tStCvJH)

EDIT: longer discussion on Reddit -
[http://www.reddit.com/r/linux/comments/1viqpt/x_server_runni...](http://www.reddit.com/r/linux/comments/1viqpt/x_server_running_without_root_privileges_now/)

~~~
antocv
This is not specific to running as root or not, its a problem with X protocol
- it doesnt isolate clients.

------
mdwrigh2
Well, if you count Android as mainstream OS then it too has GUI isolation. One
app can't receive key events when another has focus, nor can it inject events
into other applications.

------
lmz
I hear Solaris has Trusted Extensions for X11 (e.g. [1]). Would that handle
this case better?

[1]:
[http://www.desktopsummit.org/sites/www.desktopsummit.org/fil...](http://www.desktopsummit.org/sites/www.desktopsummit.org/files/gnome-
trusted.pdf)

~~~
emmelaich
Possibly; but without being familiar with TX, I would like to point that
Oracle are enhancing Solaris TX with _Flask_, which essentially _IS_ SELinux.

------
shmerl
It's an old post, but it applies to X.org all the same. Wasn't Wayland
planning on addressing these issues?

~~~
ape4
Here's some guy getting xeyes working on Wayland.
[http://blogs.gnome.org/wjjt/2012/03/14/looking-around-
waylan...](http://blogs.gnome.org/wjjt/2012/03/14/looking-around-wayland/)

~~~
EmanueleAina
That proof-of-concept relied on a custom protocol extension which, as the
author pointed out, was not meant to be merged in Wayland/Weston. In any case
the extension required application to ask the compositor to be notified of the
pointer position even when not "owning" it and the compositor can flatly
refuse it to non-privileged clients according to any policy it wants, which is
quite different from the current X11 situation.

This article has some useful information on how Wayland addresses the security
concerns expressed in this thread: [http://mupuf.org/blog/2014/02/19/wayland-
compositors-why-and...](http://mupuf.org/blog/2014/02/19/wayland-compositors-
why-and-how-to-handle/)

------
ecma
Interesting that this comes up again with Ubuntu Trusty continuing to retain
Xorg. Is anyone familiar enough with Mir and Wayland to comment on how those
packages approach this kind of thing?

~~~
flogic
Does it actually matter? For the average desktop, everything of monetary value
will be under the main user account. Which is generally also the account used
to touch the internet.

~~~
XorNot
This is a problem which needs to be fixed, as cryptolocker demonstrates.

We really need some hard boundaries set between non-interactive and
interactive requests to open files.

Sensible ones too - not "ask about every file", but maybe "grant process
access to this folder in my documents folder, without recursive access".

Even better would be "fire this backup utility _first_ , then grant access".

~~~
antocv
This could be implemented for ~ using a fuse.

------
microcolonel
Glad to see this reposted(although it being this specific article is of no
particular value, there are other articles on this which don't have such
shameless plugs).

We now have Wayland well on its way to replacing X(I'd say within two to three
years, some users won't ever know they're running Wayland), and from what I
can tell, it will offer fairly good isolation for input.

Another important step is graphics drivers being cleaned up to improve
isolation between graphical clients. For the time being, though, I can create
a GL context and not draw anything, but still see parts of the framebuffer in
my context, which I find giggle-worthy.

I think the basic problem here is that graphics systems are hard enough to
make work at all, let alone make secure. I will probably not trust a system
this complex to protect input or content for a long time, if ever.

~~~
sparkie
Blogging about a problem and giving your solution is not a _shameless plug_.
What would you prefer, an article which describes a bunch of security problems
and doesn't tell you how they can be resolved?

------
joveian
For a lot of end user systems it doesn't really matter if cross-user
protection boundaries exist or not because there is only one user on the
system. It is the lack of sub-user protection boundaries that is a big
concern.

I hadn't heard of Qubes, looks interesting.

~~~
ape4
I agree if I launch app A and I launch app B its ok if they can see what the
other is doing. But what if some nasty process launches an app. Of course,
viruses (etc) are very rare on Linux.

------
JupiterMoon
OK so I get the problem with a program running as a given user being able to
grab all of that user's key strokes.

But why try to stop something running as root from grabbing users keystrokes?
If someone has root on your box it is pretty much game over for any security
anyway. Anything that pretends that it isn't is actively bad since it will
give you a false sense of security.

So to mitigate this simply have multiple profiles. One for work, one for
banking etc and one with sudo access - and don't su into the sudo access
profile just Ctrl-Alt-F1 when needed.

------
xenophonf
Invisible Things Lab published a similar analysis of Windows GUI isolation
earlier this year:

[http://theinvisiblethings.blogspot.fr/2014/01/shattering-
myt...](http://theinvisiblethings.blogspot.fr/2014/01/shattering-myths-of-
windows-security.html)

I find the concept behind Qubes fascinating. I only wish that it was more
stable or that it supported native isolation mechanisms like FreeBSD jails.

------
doctorfoo
On my last OS reinstall, I tested out Qubes but was put off by the lack of
AppVM graphics card support (I do game development) and lack of bluetooth
(wireless mouse + headphones) support. I understand these are key security
holes and are absent for a reason, but in my view being able to enable these
would have been an acceptable compromise between usability and security - the
reality is that my personal security situation is not so critical that I am
going to go without these modern conveniences, but I would still like to make
it as difficult as possible for attackers otherwise.

Surely Qubes even _with_ these security holes would be better than vanilla
Linux? (This was roundly shot down as a proposition on the Qubes mailing list)

------
leoc
Will Wayland improve matters significantly?

~~~
ah-
Yes. See [http://mupuf.org/blog/2014/02/19/wayland-compositors-why-
and...](http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-
handle/)

~~~
cmiles74
Perhaps migrating QubesOS from X to Wayland would provide the groundwork for
GPU sharing.

------
ushi
Does anybody know, how Wayland [0] handles this? I just found one thread on
StackExchange [1].

[0] [http://wayland.freedesktop.org/](http://wayland.freedesktop.org/)

[1] [https://security.stackexchange.com/questions/3589/passive-
an...](https://security.stackexchange.com/questions/3589/passive-and-active-
attacks-via-x11-is-wayland-any-better)

~~~
nemetroid
This question is asked in the comments of the article as well, and receives an
incredibly unprofessional answer:

> (commenter) Instructive article. But what about Wayland? Wayland is claimed
> to replace X soon. Major distros are already working on its integration. Are
> the authors aware of it or does it have the same design flaws?

> (author) @phocean: good question about Wayland, why don't you check for
> yourself? ;)

> (commenter) So I will when I have some free time. But as it is your research
> topic, I expected you had already done that or even contacted the developers
> to inform them. As it is still under heavy development, I guess it is a good
> timing to implement good stuff and for expert like you to advise them.

> (author) @phocean: Don't kid me, kid! What I did here was not a "research"
> (you might want to check some real research we did at ITL on our website).
> That was just a Saturday morning blog post with an aim to save some lost
> souls, like yours... And I really don't have time to go and test all the
> software in the development that is out there. I do have real job, that
> among other things includes doing _real_ research...

------
ciupicri
The title should have _(2011)_ at the end.

------
okasaki
People bring this up sometimes, but I've never heard of this being used in any
real attack/malware. It appears to be a purely theoretical threat.

~~~
politician
Broad-spectrum attacks on our global information infrastructure appeared to be
purely theoretical until Snowden published.

~~~
okasaki
What are you referring to?

~~~
pekk
It's an obvious reference to NSA's programs for intercepting various
information

------
carver
Yikes! Yet another reason to use paper bitcoin wallets.

