
The Linux Security Circus: On GUI Isolation (2011) - dandelion_lover
http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
======
jszymborski
Am I wrong in thinking that this is sort of like worrying about leaving the
kettle-on while you're falling from a skyscraper?

Sure, if you have a rogue application on your computer, it can access the GUI
of a program whose security is critical (e.g: a password manager), but even if
all the GUI were isolated, you've still got a rogue program on your comp.

All the security posts I've ever read have pretty much told me that once
you're running a malicious program, then it's game over, your system is owned
by your adversary and the only good way to move on is to wipe the drives, and
start fresh. Why then worry about GUI isolation? If the GUI is isolated, a
rogue program can presumably uninstall your secure GUI server and replace it
with another!

This blog mentions Qubes, which is cool and does mitigate the rogue program
from what I understand, but anything short of isolating whole applications
from each other at the hypervisor-level, is fussing about the wrong thing
IMHO.

Then again, I'm not a security professional, so what I've said is likely all
wrong...

~~~
Houshalter
That's not really true. Tremendous effort has gone into making sandboxed
programs. Otherwise any website that has JavaScript could take over your
computer. The browser is basically a functioning sandboxed operating system.

There's no reason that can't be true of actual OSes. All programs could be
sandboxed by default. But they just were designed under the assumption that
all app makers would be good and no one would ever download and run malicious
programs. Yeah, right.

~~~
ffk
One such feature is the use of seccomp, which removes all but 4 system calls:

read, write, sigreturn and exit

This is used by many browsers and apps to reduce the impact of security flaws
and untrusted code (such as js from a website).

------
pdkl95
Speaking very generally (there's always room for improvement), this is a
feature. X programs are able to interact in interesting ways. Isolation can be
a good thing and I would love to have more options for sandboxing programs
(with or without X), but stuff like keylogging and sending events to windows
are very useful. Removing the ability to do stuff like query the state of the
mouse would break useful tools I use. The ability to keylog my keyboard or
mouse is a potential risk, but it's also a necessary feature. As DHH
explained[1], nerfing useful tools just causes people to find other ways to do
the same thing, sometimes with worse consequences.

The "window composition only" approach of Wayland where it is simply assumed
that this can be handled in e.g. the GUI toolkit is problematic if you have
programs that don't use that toolkit. The windowing server is really the wrong
layer implement this isolation - it makes useful things much harder while not
actually providing a lot of security; if a malicious program is already
running as the user, there are already endless ways it can harm the user
without touching the UI. Real sandboxing would be, for example, a way to open
a Wayland-style framebuffer that can be handed to a FreeBSD-style jail (or as
"hardware" in a full VM).

[1] [https://vimeo.com/17420638#t=27m27s](https://vimeo.com/17420638#t=27m27s)

~~~
the_why_of_y
Looking at this from the other end, the problem is, as long as clients of the
window server aren't isolated against each other, any other kind of sandboxing
(such as restricting file system access) is pointless: a compromised
application can just synthesize input events for some other application to
give it what it wants.

The next step towards real sandboxing is applications with cgroups and
namespaces (quite similar to FreeBSD jails), as in xdg-app.

[https://wiki.gnome.org/Projects/SandboxedApps/Sandbox](https://wiki.gnome.org/Projects/SandboxedApps/Sandbox)

~~~
pdkl95
> any other kind of sandboxing (such as restricting file system access) is
> pointless

That's my point - I don't _want_ most of my "desktop" applications sandboxed
from each other. That would be unusable. That kind of sandboxing should be
done by nesting the entire display server, creating a separation point.

In the future, with all clients sandboxed from each other, how can I write a
tool that does the following (which was easy under X):

* monitors the keyboard input of another process

* sends new (synthetic) key events to that process when it sees a certain key press (keyboard macro)

* does not depend on _any_ support from the process being monitored

* works with any existing program, including proprietary software that cannot be recompiled because the source has been lost

Interaction is necessary at the GUI layer, because that's the _intended goal_
of some software. As I initially said, there is certainly room for
improvement. However, simply pretending these use-cases don't exist is
foolish. As Joel Spolsky so famously explained[1], all that "cruft" that is
cut out during a big rewrite is real-world fixes and necessary features that
were added over time. Unfortunately, the GNOME team has been engaging in that
kind of narcissism for many years, which is why more and more people are
ignoring them.

> real sandboxing

> cgroups and namespaces

Good luck with that; cgroups and namespaces are not designed for security.
They are only superficially like jails.

[1]
[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

------
cpitman
It isn't addressed in the post and the author gets kind of defensive about it
in the comments, but this is one of the things that Wayland is supposed to
improve on. Each application can only communicate with the compositor about
its own windows, and only has access to a buffer with it's own content.

I'm honestly not sure where we are on the adoption path for Wayland. Pretty
much all of my Linux usage is command line.

~~~
naner
Wayland was planned as default for Fedora 24 but has been postponed[1]. I
don't think it is on by default in any flagship distributions yet.

1: [https://blogs.gnome.org/mclasen/2016/03/04/why-wayland-
anywa...](https://blogs.gnome.org/mclasen/2016/03/04/why-wayland-anyway/)

~~~
ape4
Also certainly it will be in Fedora 25 (in under a year). From there it will
be in everything else. Good to see this problem about to go away.

~~~
zanny
It already works fine under Gnome, every major Gnome distro should be
switching either late 2016 or early 2017. I cannot imagine Ubuntu Gnome _not_
switching in 16.10.

KDE is a little bit more behind, but I'd postulate well working Wayland
somewhere around Plasma 5.8 - we are going to see 5.6 come out in a few
months, and 5.8 is the start of next year. KDE themselves have had to propose
tons of extensions to Wayland itself to support functionality they use -
server side decorations, screenshotting, key grabbing, etc.

------
nickpsecurity
This was one of the features I mentioned in my original critique of QubesOS
that commercial & academic products had. I was glad to see they added trusted
GUI. Anyone interested in prior work on trusted GUI's for how they might be
applied today can check the links below:

A prototype B3 Trusted X Window System (1991)

[https://www.acsac.org/secshelf/papers/Epstein.pdf](https://www.acsac.org/secshelf/papers/Epstein.pdf)

High-performance hardware-based high-assurance trusted windowing system (1996)

[http://csrc.nist.gov/nissc/1996/papers/NISSC96/paper041/tx-h...](http://csrc.nist.gov/nissc/1996/papers/NISSC96/paper041/tx-
hdw.pdf)

Design of the EROS Trusted Window System (2004)

[https://www.usenix.org/legacy/event/sec04/tech/full_papers/s...](https://www.usenix.org/legacy/event/sec04/tech/full_papers/shapiro/shapiro.pdf)

A Nitpicker's Guide to Minimal-complexity, Secure GUI (2005)

[https://www.acsac.org/2005/papers/54.pdf](https://www.acsac.org/2005/papers/54.pdf)

~~~
edwintorok
Nitpicker is part of Genode, right? Whats the status of Genode, is it usable
as a daily OS?

~~~
nickpsecurity
Nitpicker is from TU Dresden's group that was doing all kinds of work on L4,
secure virtualization, etc. Originally part of their TUD:OS demo here:

[http://demo.tudos.org/eng_features.html](http://demo.tudos.org/eng_features.html)

Feske, a Nitpicker author, later developed the Genode Framework for
constructing systems as part of European research into Dresden-style stuff. He
wisely integrated Nitpicker, NOVA, and other best-of-breed tech coming out of
CompSci where he could. Plus stuff from OSS that's important for a usable
system. Result his people call GenodeOS although many of the pieces, even
architecture, are reusable outside of it.

GenodeOS itself is at what I'd call an alpha stage where it's usable enough
that people are running desktops on it but more for testing and error reports.
;) They've come quite a way but need more testing and contributions. It's not
production by far unless you're backing up data.

Even so, alpha software can cost you productivity with the reinstalls so best
to use them alongside another machine with same data that can keep you going
during any restores.

GenodeOS Release 16.02 is latest [http://genode.org/documentation/release-
notes/16.02](http://genode.org/documentation/release-notes/16.02)

Note: They support RISC-V now. That's pretty cool. The combo of RISC-V with
separation kernels like Muen and seL4 (both supported) will be important for
secure, embedded solutions later.

------
resoluteteeth
I really think the linux desktop world is making a huge mistake by not
worrying about stuff like this.

We really, really to figure out secure booting and sandboxed applications in a
way that leaves the user in control. Desktop linux has been fairly safe
because it's not an important target and because most users get most of their
software through distributions.

However, I don't think in 2016 we should just take it for granted that one
malicious program should be able to effortlessly own the user agent and
probably the entire system (on a computer with one user who uses "sudo").

The problem is that these technologies have been associated, especially in
android/ios, with restricting what the user can do. However, this does not
need to be the case.

Until recently, most people's data on their computer wasn't too valuable, but
malware has gotten more sophisticated at targeting things like bank
information. If we wait for linux desktop security to become a serious issue,
it will be too late.

The worst thing is that we already have things like SELinux and AppArmor, but
they aren't being used. The insecurity of X is no joke, either. We may getting
close to a point where we have no choice but to throw out X just to get
security, even if the other reasons for switching aren't that compelling.

------
gizmo
Another huge issue is that user-level programs can access all everything in
the user's home directory which is where all valuable data resides. There is
no reason why a tetris game should get access to all your financial documents,
but that's how it works today. A single malicious user-level program can
destroy everything of value on your computer and no elevated permissions are
required. In contrast to iOS where all app data is siloed off, exactly as it
should be.

~~~
ris
"In contrast to iOS where all app data is siloed off, exactly as it should
be."

Which is also why trying to do anything _productive_ on a smartphone is such
an uphill battle. Arbitrary programs not being able to exchange arbitrary
files is totally crippling for any use-cases that go off the rails of what one
single app wants to let you do.

~~~
marcosdumay
There ought to be a system level API that a program may call to get to read or
write a user supplied file.

Opening any random file should be reserved to just a few core applications.

~~~
drdaeman
It's not that simple, and it's easy to misdesign such API.

Say, VLC team had argued that a video player may need to open a supplementary
subtitle file. If application can be only granted access to a single video
file - that's impossible. I think there were other examples, but I don't
remember those off-hand.

~~~
nine_k
Filesystems are trees. VOX could have read access to a particular tree
(~/Videos) and no access to everything else, including but not limited to
~/Documents/Finance

~~~
drdaeman
But what if I want to watch ~/Downloads/big_buck_bunny.mkv?

~~~
nine_k
Explicitly mark it as available by moving / hardlinking it to ~/Videos.

------
bm98
As I posted in a previous discussion of this two years ago [1]:

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.

[1]
[https://news.ycombinator.com/item?id=7607082](https://news.ycombinator.com/item?id=7607082)

------
m3h
So what is the current status of GUI isolation in Linux (say Ubuntu), Windows
and MacOS?

------
tlug
That is a very old article, I wonder if there are any new approaches to this
issue.

~~~
agwa
I've been researching this recently and I think the Qubes approach is still
the best. Some people use xpra, which is fundamentally very similar to Qubes
(a compositor running inside a dummy X server), but xpra has been designed to
run over the network and hence is not as efficient as Qubes with transferring
buffers. Consequentially, I find xpra to be too slow to be usable. xpra also
has gained a lot of additional features lately which I worry has increased the
attack surface.

Coincidentally, I was planning to spend some time today porting Qubes' GUI
isolation to run outside of Qubes (for use between containers or other OS-
level sandboxes). If I'm successful, expect to see a Show HN.

~~~
heavenlyhash
> porting Qubes' GUI isolation to run outside of Qubes (for use between
> containers or other OS-level sandboxes)

Want level >9000.

------
ekianjo
Isn't Wayland supposed to address this kind of issue (X applications being
able to read/control what others do) ?

~~~
the_why_of_y
Yes, it is.

For more details about the issues and possible solutions read:

[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/)

------
gsteinb88
Previous discussion (~5 years ago):
[https://news.ycombinator.com/item?id=2477667](https://news.ycombinator.com/item?id=2477667)

------
ris
It is of course entirely possible to run a less-trusted application in a
nested xserver like xephyr in any distribution and avoid this.

~~~
agwa
Yes, but that's not "rootless." The Qubes approach provides much better
usability because the windows from the untrusted application appear
individually and are managed by the host X server.

~~~
ris
I don't dispute this.

------
dingdingdang
Qubes OS is super cool conceptually - torrenting it so when I've got time to
spare I'll see if I can practically get it running, would LOVE to replace the
current messy and insecure Linux/OSX/Windows systems with a new secure and
stable OS that includes sandboxing by default for everything.

------
asveikau
At one point I disabled the XTEST extension when I realized it could be used
maliciously (sending clicks or keystrokes to applications, keylogging, etc.)
XTEST is already disabled by default on some distros.

After reading this I see that "xinput test Keyboard0" can also be used as a
keylogger on my machine. Anybody know of a simple way to disable that one?

[PS: please no trollish answers like "use a different windowing system" :P]

~~~
digi_owl
Xinput is an extension, so it should be possible to disable via xorg.conf.

~~~
duskwuff
Xinput is a very old, very widely used extension, and handles much more than
just input sniffing. Disabling it will remove a lot of really important core
functionality like setting keyboard mappings and mouse acceleration. It's also
likely to break certain applications which legitimately need to capture
events, like screen savers.

~~~
asveikau
Yes, it's sadly ironic that things are modular enough to make xinput an
extension of the protocol, but not modular enough to separate the very useful
looking functionality in the xinput(1) manpage with a keylogger.

~~~
digi_owl
One mans keylogger is another mans debugger.

Note that the command is "xinput test id". Meaning that it is a way to monitor
what xinput sees when a key or button is pressed.

I have personally used xev for similar purposes, map my keyboard's multimedia
keys to various actions.

------
bitwize
It should be possible (and default in the X server really) to isolate X
clients by only giving them access to the contents of, and events on, the
drawables created by that particular client.

Combined with a way to authenticate privileged apps (which have permission to
sniff for any input event and scrape any drawable), you can have your...
security cake and eat your... screen grabbers and Guake hotkeys... too?

~~~
bitwize
As it turns out, there are X11 extensions (SECURITY, XACE) which mitigate this
problem somewhat, and Xorg has an extension (XSELinux) which allows fine-
grained access control to X11 objects via SELinux policy. It's just that the
distro vendors don't actually choose to enable it. (Red Hat seems to prefer
sandboxing with Xephyr, or else force-migrating everyone to Wayland.)

------
elchief
Just pull the trigger and upgrade to OpenBSD.

    
    
      Xenocara (least-privilege x11)  
      libc  
      LibreSSL

~~~
na85
I'd love to but it runs horribly on my thinkpad. My choice is between
10-second system freezes when opening or closing or switching browser tabs
(i.e. with APM on), or else a 2-hour battery life (with APM off).

On a Sandy Bridge i7.

OpenBSD is pretty good for servers (I run one), but my experience has been
that it's just total shit on the laptop.

------
digi_owl
Elsewhere i read about using vnc locally to run something as different user.

That seems to block this, though not for the reason i expected (i get an error
about a mission extension when i try to run xinput list).

------
bakhy
a bit unnerving. why wouldn't some ad-tracking mechanism that's part of some
apps simply collect everything it can and radio it back home?

btw, can this be considered a huge security plus for web apps? they can break
out, but at least they have to put in some effort.

~~~
anon1385
>why wouldn't some ad-tracking mechanism that's part of some apps simply
collect everything it can and radio it back home?

Because the vast majority of GUI software installed on Linux comes from
curated app stores (or 'repos' as they used to be called). It's also mostly
written without any expectation of making money.

Web apps being sandboxed is a plus point for users in the sense that it
increases security (on the local machine - the web app vendor is still free to
do whatever they want with your data). It's also a negative since it means any
code you want to execute on your own hardware has to be approved by the
browser vendors (web standards don't really provide any user controlled way to
break out of the sandbox[1]). The standards generally operate in a lowest-
common-denominator way such that the vendor of a browser your don't even use
can prevent you from utilising your own hardware by stalling web standards
indefinitely.

[1] the old plugins interfaces like NPAPI do exist, but are being phased out
and aren't supported at all on web-only platforms like ChromeOS and FirefoxOS,
as far as I'm aware

------
zurn
xorg developers seem to think the X server currently does cover this:
[https://bugs.freedesktop.org/show_bug.cgi?id=38517](https://bugs.freedesktop.org/show_bug.cgi?id=38517)

------
okasaki
A non-problem in practice as far as I can tell. It's also a very convenient
feature.

~~~
bakhy
i personally would appreciate a security popup from the OS asking me if i want
to give full access to an input to any app. otherwise, to each only his own,
and the possibility of applying for global shortcuts perhaps...

