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

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 user!):

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

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.

Why the US "password revolution" won't work

So, I've been reading this article this morning on how the US "private and public" institutions are going to revolutionize the way we authenticate on the web. The "ground breaking" idea, also illustrated on this NIST animation, is to use 3rd party authorities that would first verify your identity somehow ("Can we see your id?", "What is your Mam's maiden name?", etc), and then would issue you some kind of a token that you would later use for authentication on the web. A token would be e.g. a smart card, or a USB stick (probably they just mean a smart card with USB connector, whatever), or even a "phone application".

The idea is that the user will not have to "remember" all those passwords for all the various websites, which apparently is a problem in practice, because most users never heard about password manager apps, and so they actually try to remember all those passwords, or even try to use the same one all over the place. Using one password for more than one website is obviously wrong and people should be told not to do that. But an easy way to solve this is to just get people to use password managers.

But the key problem that they try to solve, which is identity theft, is just not gonna be solved by this "password revolution". This is because if somebody has compromised my laptop, then it really doesn't matter if I use passwords, or smart cards, or whatever other multi-factor authentication mechanism -- none of them will help if the attacker controls my operating system.

Most people cannot just get it -- this is because they lack understanding of how computers and operating systems work. They don't understand that the operating system can impersonate the user at will! This is because the operating system fully controls the keyboard, the mouse, and the screen.

So, imagine you use your super-secure smart card token for authentication to your bank. So, before you log into your bank account, and perhaps before you make any transaction on the banking website, you must insert your smart card somewhere (e.g. into smart card reader, or into USB port, etc). Before you insert your token, no one can impersonate you on the bank website. So far, so good! But then, once you inserted your token, it's all lost! The compromised OS could have saved your PIN to this card when you used it previously (even if you configured it not to do so!) and now,  immediately, it could use the inserted card to authenticate as you to the bank and start issuing transactions on your behalf. And you won't even notice this all, because in the meantime it will show you a faked screen of your banking account. After all, it fully controls the screen.

The bottom line is that we cannot secure our digital lives, if our client operating systems could not be secured first. And today, the operating systems we use on our laptops, such as Windows, or Mac, or Ubuntu, are just trivial to be compromised by the attackers. After all, if that wasn't true we wouldn't have all those problems with identity theft. But introduction of tokens won't make our operating systems any more secure!

What we need instead are technologies that allow to build next-generation trusted operating systems. Technologies such as Intel TXT or VT-d. And we need OS vendors to actually start using them.

You can say I'm biased, because of our work on Qubes OS. But then, consider this -- perhaps we would never invest so much money and resources into this project, if we believed there are other ways to bring security to our digital life.

Qubes Beta 1 has been released!

I'm very proud to announce that we have just released Qubes Beta 1! Some new features that have come into this release include:

• Installer (finally!),

• Improved template sharing mechanism: service VMs can now be based on a common template, and you can now easily create many net- and proxy- VMs; template upgrades now don't require shutting down all the VMs;

• Standalone VMs, convenient for development, as well as for installing the least trusted software,

• Built in, easy to use firewall VM(s),

• Seamless integration of virtualized tray icons (check the screen shots!)

• Redesigned file-copy between domains (easier, more secure),

• Default template based on Fedora 14 (x64)

• Reasonably complete User Guide.

... and many other improvements and bug fixes!

To download the installation ISO go to this page.

You can also install Qubes on an external USB disk - this might be a convenient option if you want to just try it out, without the need to "sacrifice" your laptop.

This release is very stable, but we feel that it still requires some more polish, mostly with regards to user interface. We're planning to release at least one more beta, in about 2 months, where we will focus mostly on UI improvements, and also on upgrading Xen and kernel in Dom0 to allow for better hardware support.

The final Qubes 1.0 is planned after the summer holidays. Once we reach this milestone, further work will likely fork into two branches:

• The "commercial branch" which will focus on adding various extensions on top of Qubes 1. One specific commercial extension that we think would be a killer is support for Windows-based domains (AppVMs),

• The "open source branch" that will continue on implementing even more revolutionary architecture and features, such as untrusted storage domains, safe GPU multiplexing, trusted boot, etc. In the end this should lead to Qubes 2.0 sometime in 2012 or 2013.

Cross your fingers!