ace of hackers's blog

The Linux Security Circus: On GUI isolation

The Linux Security Circus: On GUI isolation
There certainly is one thing that most Linux users
don't realize about their Linux systems... this is the
lack of GUI-level isolation, and how it essentially
nullifies all the desktop security. I wrote about it a
few times, I spoke about it a few times, yet I still
come across people who don't realize it all the time.
So, let me stress this one more time: if you have two
GUI applications, e.g. an OpenOffice Word Processor,
and a stupid Tetris game, both of which granted
access to your screen (your X server), then there is
no isolation between those two apps. Even if they run
as different user accounts! Even if they are somehow
sandboxed by SELinux or whatever! None, zero, null,
The X server architecture, designed long time ago by
some happy hippies who just thought all the people
apps are good and non-malicious, simply allows any
GUI application to control any other one. No bugs, no
exploits, no tricks, are required. This is all by design.
One application can sniff or inject keystrokes to
another one, can take snapshots of the screen
occupied by windows belonging to another one, etc.
If you don't believe me, I suggest you do a simple
experiment. Open a terminal window, as normal
user, and run xinput list, which is a standard
diagnostic program for Xorg (on Fedora you will likely
need to install it first: yum install xorg-x11-apps):
$ xinput list
It will show you all the pointer and keyboard devices
that your Xorg knows about. Note the ID of the device
listed as “AT keyboard” and then run (as normal
$ xinput test id
It should now start displaying the scancodes for all
the keys you press on the keyboard. If it doesn't, it
means you used a wrong device ID.
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!
Yes, I can understand what is happening in your
mind and heart right now... Don't worry, others have
also passed through it. Feel free to hate me, throw
out insults at me, etc. I don't mind, really (I just won't
moderate them). When you calm down, continue
In Qubes the above problem doesn't exist, because
each domain (each AppVM) has it own local, isolated,
dummy X server. The main X server, that runs in
Dom0 and that handles the real display is never
exposed to any of the AppVMs directly (AppVMs
cannot connect to it via the X protocol). For details
see this technical overview.
You can repeat the same experiment in Qubes. You
just need to use the ID of the “qubesdev” device, as
shown by xinput list (should be 7). Run the xinput in
one of your domains, e.g. in the “red” one. Because
we actually use the same device for both mouse and
keystrokes, you should now see both the key
scancodes, as well as all the mouse events. Notice
how your xinput is able to sniff all the events that are
destined for other apps belonging to the same
domain where you run xinput, and how it is unable to
sniff anything targeted to other domains, or Dom0.
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. See e.g. this ancient article I wrote in the days
when I used Vista at my primary laptop. Of course,
it's still easy to bypass this isolation, because of the
huge interface that is exposed to each GUI client (that
also includes GPU API). Nevertheless, they at least
attempt to prevent this at the architecture level.

Syndicate content