The Linux Security Circus: On GUI isolation
theinvisiblethings.blogspot.com
The Linux Security Circus: On GUI isolation
1–10 of 50 posts
Re: The Linux Security Circus: On GUI isolation
#2I 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.
Re: The Linux Security Circus: On GUI isolation
#3The 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!!!
Re: The Linux Security Circus: On GUI isolation
#4Now, 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 problem it's made out to be:
1. An application running as a different user can only connect to the X server if it has access to the .Xauthority file. This means there's no risk of having another user connect to your X session and sniff keystrokes, unless you explicitly chmod o+r ~/.Xauthority.
2. One should never run untrusted applications.
Now, I will grant that better GUI process isolation and/or granular X permissions would be useful, in that it would lay the groundwork for a safe way of allowing an untrusted remote (or local) process to display a GUI on the local X screen. I've also always wished window managers would highlight windows from a different user with a red border, mostly so I could tell which file browser window I'd started with sudo.
Re: The Linux Security Circus: On GUI isolation
#5The 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.
Re: The Linux Security Circus: On GUI isolation
#6I 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 enabled for a field, no other application can intercept those events.
Re: The Linux Security Circus: On GUI isolation
#7I 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.
In the OS X GUI, the Authorization Services API handles this. The SecurityAgent process, running as a different uid (_securityagent), controls the window that the user enters her password to escalate privileges.
Re: The Linux Security Circus: On GUI isolation
#8ssh 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.
Re: The Linux Security Circus: On GUI isolation
#9I 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…
xinput is still able to read all keys when xterm's secure keyboard is enabled.
Re: The Linux Security Circus: On GUI isolation
#10Earlier quoted context omitted.
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…
xinput is still able to read all keys when xterm's secure keyboard is enabled.
right, because it's not operating on x11 events, it's just directly reading xinput data. there's not much xterm can do when the underlying server is giving away all of the raw input data.