P(a)draigBrady.com 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