P@xxxxxxxxxxxxxx wrote on Thursday 06 January 2005 09:47: > The FC3 release notes say: > > "The behavior of ssh clients that are invoked with the -X flag has > changed. In OpenSSH 3.8 and later, X11 forwarding is performed in a > way that applications run as untrusted clients by default. > Previously, X11 forwarding was performed so that applications always > ran as trusted clients. Some applications may not function properly > when run as untrusted clients. To forward X11 so that applications > are run as trusted clients, invoke ssh with the -Y flag instead of > the -X flag, or set ForwardX11Trusted in the ~/.ssh/config file." > > See also: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141515 > > Essentially what this means is that most X applications will > break if forwarded back to a FC3 system with default config. > Now it wouldn't be so bad if they just wouldn't work. > They break in subtle ways usually related to mouse events. > This is just silly IMHO and will cause no end of hassles > for users trying to figure out what's going on and > also be a waste of time for developers of those X apps > who will receive bogus bug reports. > > So can we change the upstream default back to what it used to be? It's not just silly -- it reduces the size of a security hole. If X apps can be fixed to deal with running as an untrusted X client, then they should be fixed. If a given X app can't be run untrusted, I don't know what to suggest. Here's the security problem with running as a trusted client. If I ssh -Y (or ssh with old defaults) into a machine where someone else can use my xauth cookie (e.g. the remote machine has a compromise of my account or of root), then the compromiser can read not only my keystrokes on the remote machine, but my keystrokes on my desktop. That's bad. If I tell ssh to treat tunneled X clients as untrusted (the new default behavior), on the other hand, then remote intruders cannot read my local, trusted-client keystrokes. They can still read my keystrokes on other untrusted clients (e.g. an xterm on a different remote ssh-accessed machine), but that's not quite as bad as the old default. X only has this untrusted/trusted distinction; it probably really needs a widely-used, more featureful security model. All this is *my understanding* of X security, based on reading rather than direct testing; if I got something wrong, please correct me. :) David
