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

31–40 of 50 posts

Re: The Linux Security Circus: On GUI isolation

#31

Post by Groxx »

runningdogx wrote: post #5
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!!!

...a major difference being there are not robots yet that can go around breaking into people's less-secure houses and torturing residents for information, all in an automated fashion.

Thankfully, there's Old Glory for protection against such things: http://www.hulu.com/watch/2340/saturday-night-live-old-glory

Re: The Linux Security Circus: On GUI isolation

#32

Post by trotsky »

cygwin98 wrote: post #30

Maybe I misunderstood this article. It seems to me there is a security issue in X Server, which gives out keyboard input info to all running X apps. That's fine. If that's X Server, just fix it then everyone will be happy. Why introduces all the Xen/VM stuffs into this problem. It is like you have a mosquito flying around, but you choose to kill it using a nuclear bomb.

I'm sure that they didn't set out to solve just this one problem. Rather there are a whole slew of problems that per process vm sandboxing could solve (and a number that it could create). They're just interested in advertising their newly beta OS, and they are pointing out an issue they see in the X architecture that their solution happens to mitigate.

Re: The Linux Security Circus: On GUI isolation

#33

Post by tedunangst »

rst wrote: post #27
tedunangst wrote: post #17

Earlier quoted context omitted.

Note that hasn't been true for years and years. -Y and -X are different.

So, trying again... here are the caveats on -X, from the man page on the current version[1]: -X Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file. X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X authorization database) can access the local X11 display through the forwarded connection. An…

That's why the next paragraph exists.

    For this reason, X11 forwarding is subjected to X11
    SECURITY extension restrictions by default.  Please
    refer to the ssh -Y option and the ForwardX11Trusted
    directive in ssh_config(5) for more information.

Re: The Linux Security Circus: On GUI isolation

#34

Post by dreww »

Groxx wrote: post #31
runningdogx wrote: post #5

Earlier quoted context omitted.

...a major difference being there are not robots yet that can go around breaking into people's less-secure houses and torturing residents for information, all in an automated fashion.

Thankfully, there's Old Glory for protection against such things: http://www.hulu.com/watch/2340/saturday-night-live-old-glory

Old Glory is no protection at all - it's just there to compensate your loss in the even of a robotastrophe. Insurance.

Re: The Linux Security Circus: On GUI isolation

#35

Post by DisposaBoy »

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…

A trick I've used forever to make my other user's GUI apps stand out is to make a copy of my preferred theme into my own ~/.themes, change the name and use that. When I open the GUI apps as other users they are displayed with a broken theme which in the case of GTK is ugly and sticks out quite a well.

Re: The Linux Security Circus: On GUI isolation

#36

Post by rwmj »

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…

For KVM, we've implement SVirt. We don't trust the main userspace (qemu-kvm) process, and assume that it has been subverted by the guest. We contain it using SELinux rules.

http://selinuxproject.org/page/SVirt

This is now a standard feature in Fedora (since Fedora 11):

http://fedoraproject.org/wiki/Features/SVirt_Mandatory_Acces...

Re: The Linux Security Circus: On GUI isolation

#37

Post by viraptor »

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?

No, but that's where escalation comes in. You go to a page which uses javascript to take over your browser. Now your browser can capture and send back your shell password captured from the terminal window.

Re: The Linux Security Circus: On GUI isolation

#38

Post by rg3 »

rg3 wrote: post #12

Does anybody know by any chance how does the Wayland server work in this regard?

Replying to myself. I just read the architecture document for Wayland, which can be found at:

http://wayland.freedesktop.org/architecture.html

The document explains that the Wayland compositor, when receiving an input event coming from the kernel input drivers, decides which window has to receive the event and sends it to the application.

If it really works that way, native Wayland clients could be isolated from other clients and they would not receive input events directed to another client. But, in practice, the Wayland server could have facilities for clients to register and receive all the events, so I'm not sure how all of this would turn out.

Re: The Linux Security Circus: On GUI isolation

#40

Post by gaius »

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?
Post reply on HN