zlacker

>>wglb+(OP)
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 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.

>>nitrog+43
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()).

>>teduna+A5
I think this is what android does, isn't it. Although android doesn't use x.