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

11–20 of 50 posts

Re: The Linux Security Circus: On GUI isolation

#11

Post by rg3 »

there wrote: post #6
follower wrote: post #2

I seem to recall the "Secure Keyboard Entry" option (in the application menu) in Terminal on OS X is supposed to stop the su/sudo problem on OS X at least for terminals.

xterm has a secure keyboard option from its menu (control+click) that is supposed to prevent other applications from being able to receive X11 events related to input. the thing you are referring to on os x is similar, with a system-wide capability. when you enter passwords for keychain and similar things, these have secure input enabled by default. i think it's up to the application to enable it, but when it's enabl…

Thanks for pointing out the "Secure Keyboard" option. Make sure to test it before relying on it, though. I just tested in my system and it does not prevent "xinput test" from receiving the key presses, even when typing the "su" password.

Re: The Linux Security Circus: On GUI isolation

#14

Post by tzs »

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…

You can't always avoid untrusted applications if you use the net, unless you make sure to only use client software that has no exploitable bugs that can lead to local code execution.

Re: The Linux Security Circus: On GUI isolation

#15

Post by rst »

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…

"One should never run untrusted applications."

So, what applications do you trust, to never, under any circumstances, get subverted by third parties? I don't know about you, but I personally find it hard to have that level of trust in anything that's written in C, and talks to the network --- but without any of those, these days, you're left with a pretty spartan and uncomfortable environment.

Besides which, allowing any app to read any other's keystrokes, without special arrangement is a pretty clear violation of the principle of least privilege. It may have been appropriate for research environments twenty years ago ("hey, the window manager can be just another app! isn't that neat?"), but Rutkowska's quite right to say that it's not good design for the world that we're living in now...

Re: The Linux Security Circus: On GUI isolation

#16

Post by ericb »

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…

> One should never run untrusted applications.

Security through omniscience? Is that any kind of answer? This is a whole that can be plugged.

Re: The Linux Security Circus: On GUI isolation

#17

Post by tedunangst »

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.

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

Re: The Linux Security Circus: On GUI isolation

#19

Post by tedunangst »

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 as untrusted clients. GTK, for instance, will more or less immediately abort because its error checking consists of assert(trusted_only_operation()).

Re: The Linux Security Circus: On GUI isolation

#20

Post by tshtf »

tedunangst wrote: post #17
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.

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

That's why I mentioned the -X option... -Y handles the problem the correct way and doesn't have the same issues.

Edit: Ignore this, I was incorrect.

Post reply on HN