Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux Security Circus: On GUI isolation

theinvisiblethings.blogspot.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: The Linux Security Circus: On GUI isolation

#41

Post by gaius »

jrockway wrote: post #3

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

Absolutely!

The bad press X gets is like banning HTTP because someone broke into your webserver once...

Re: The Linux Security Circus: On GUI isolation

#42

Post by tzs »

doki_pen wrote: post #24

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.

> Do people run root GUIs as a client? That seems silly to me.

When you need to su or sudo, do you switch away from X to a separate virtual console, or do you just do it in an xterm (or equivalent)?

How about when you want to ssh to a server and do something, possibly including su or sudo on the server. Again, do you do that from an xterm or equivalent on your desktop machine, or do you switch out to a separate virtual console for all your ssh activity?

Re: The Linux Security Circus: On GUI isolation

#43

Post by jamii »

gaius wrote: post #40
trotsky wrote: post #28

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…

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?

Similarly, but much less mature, Mirage runs the ocaml RTS directly on top of Xen: http://openmirage.org/

Re: The Linux Security Circus: On GUI isolation

#44

Post by gaius »

jamii wrote: post #43
gaius wrote: post #40

Earlier quoted context omitted.

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?

Similarly, but much less mature, Mirage runs the ocaml RTS directly on top of Xen: http://openmirage.org/

I've heard of Mirage and am looking forward to it being ready for prime-time :-)

Re: The Linux Security Circus: On GUI isolation

#45

Post by aristidb »

jamii wrote: post #43
gaius wrote: post #40

Earlier quoted context omitted.

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?

Similarly, but much less mature, Mirage runs the ocaml RTS directly on top of Xen: http://openmirage.org/

Or, for Haskell on Xen: http://halvm.org/wiki/

Re: The Linux Security Circus: On GUI isolation

#46

Post by 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.

Re: The Linux Security Circus: On GUI isolation

#47

Post by sciurus »

tshtf wrote: post #8

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.

'-X' is supposedly the safe alternative to '-Y'. However, as a Cygwin/X maintainer says "this is widely considered to be not useful, because the Security extension uses an arbitrary and limited access control policy, which results in a lot of applications not working correctly and what is really a false sense of security"

http://cygwin.com/ml/cygwin-xfree/2008-11/msg00154.html

Re: The Linux Security Circus: On GUI isolation

#49

Post by rtaycher »

tedunangst wrote: post #19
nitrogen wrote: post #4

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 pr…

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 a…

I think this is what android does, isn't it. Although android doesn't use x.
Post reply on HN