Re: What's the deal on the -X vs -Y thing?

From: Darren Tucker (dtucker_at_dodgy.net.au)
Date: 01/26/05 

Date: 26 Jan 2005 00:43:29 GMT

In article <ct6g89$17tt$1@hedeland.org>, Per Hedeland <per@hedeland.org> wrote:
>In article
><41f61b0c$0$10545$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
>dtucker@dodgy.net.au (Darren Tucker) writes:
>>Now try it with those lines moved to the upgraded systems' global
>>ssh_config (ie /usr/local/etc/ssh_config or wherever you've configured
>>--sysconfdir to be). This is actually what I (and the FAQ) suggested.
>
>It actually did occur to me (after posting) that this was what you (and
>the FAQ) were suggesting (with just the file name given it's ambiguous
>of course), but I couldn't really believe that...

I didn't think the filename was ambiguous (the name of the per-user
config file is "config" not "ssh_config" and is usually referred to as
"$HOME/.ssh/config" where it matters) but I can certainly make the FAQ
clearer on this.

>This cure is worse
>than the disease IMHO - the system-wide default should be that
>X11-forwarding is turned off altogether (which it is in a standard
>OpenSSH install as far as I can see).

I think you misunderstand what ForwardX11Trusted does: it enables
trusted cookies *if* X forwarding is enabled. It doesn't enable X
forwarding by itself, you have to add "ForwardX11 yes" or "-X" too
(try it).

"ssh -Y" is shorthand for "ssh -o ForwardX11=yes ForwardX11Trusted=yes".

>>So put it in the per-host config on the post-3.8 systems not in the
>>per-user configs that are shared by all. This means that you're reverting
>>to the previous, insecure behaviour for all outbound connection (but that
>>appears to be what you're arguing for below anyway).
>
>No, the previous behaviour (see above) was that X11-forwarding was off
>by default, and the individual user could override that (on a per-
>destination-host basis) with -X on the commandline or "ForwardX11 yes"
>in his $HOME/.ssh/ssh_config.

This is still the default behaviour if you have "ForwardX11Trusted yes"
in a "Host *" block, provided you don't also set ForwardX11.

>The new behaviour is that the user has to
>know the installed version or use trial-and-error to choose between -X
>and -Y, and that his $HOME/.ssh/ssh_config may be unusable for the
>purpose.

In your previous post, you argued that changing the default was a bad
move from a backwards compatibility POV. I'm arguing that the previous
default behaviour can be trivially restored (see above), so if/when
problems with the X apps were identified in pre-deployment testing
the flag can be added to the ssh_config at the time of deployment.

(Alternatively, the X server policy could be updated so that untrusted
cookies permit those operations, but I'm not sure what the security
implications of this would be.)

>(OK, there's an assumption here that most everyone that wants
>X11-forwarding wants the -Y variant - and if you were to take a poll
>explaining that "-Y is less secure, but if you use -X and try to
>cut'n'paste, your X11 app will be summarily killed", I'm pretty sure
>that the outcome would support that assumption.)
>
>Granted, this situation is likely to result in precisely the sort of
>"fix" that you suggest - and then where's the security improvement that
>should supposedly be achieved by changing the meaning of -X and
>ForwardX11? The end result is instead a reduction in security, as even
>those that don't care about X11-forwarding at all get the "trusted"
>variant by default.

No, the worst case is that people will set "ForwardX11Trusted yes"
globally, and even then they're no worse off than they were with
previous versions of OpenSSH, or if the default had not been changed
(which is what you were arguing for, right?). They still have the option
of setting it to "no" for high-risk hosts (eg outside firewalls).

On the other hand, people for whom it works now have the added security
of the untrusted cookie.

>And your work is much appreciated - but I didn't write or mean "-only",
>nor was I thinking of the portability per se. Rather my feeling (and
>that's all it is) is that the design choices made in OpenSSH development
>tend to "by default" follow "the OpenBSD model", which, in my flawed and
>simplified understanding, is to *always* choose the most "literally
>secure" alternative in any tradeoff against usability.

It's true that the "OpenBSD model" will tend toward being secure by
default (that's the motto, after all), but not to the complete exclusion
of usability.

If security was the only concern:
 - privsep would be mandatory
 - StrictModes would be mandatory
 - SSHv1 would not be supported (it's cryptographically weaker than v2)
 - Portable's sshd would not support PAM (it's tricky to get right and the
   rules are subtly different on different platforms).
 - the arcfour cipher would not be supported (it's relatively weak compared
   to the other standard ciphers but it's fast)

In these cases, the usability benefits if supporting or enabling by
default outweigh the risks. Also note that the admin can change any of
them if required. Same applies to ForwardX11Trusted.

You're arguing that changing the default was a bad tradeoff from a
security-vs-usability POV. I can respect your opinion but I think we're
going to have to agree to disagree. 

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.