Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Colin Watson
On Sun, Feb 22, 2015 at 10:31:08PM +0000, Philip Hands wrote:

> It seems to me it needs something along the lines of this near the -X
> and -Y options' documentation:
>
>   ***WARNING***
>
>     -Y option is basically irrelevant as the result of Debian
>        shipping a modified binary that treats -X the same way.
>        You'll need to set ForwardX11Trusted to "no" if you want the
>        documented behaviour that is provided upstream.
>
>   *************
>
> The patch that makes this change is here:
>
>   http://sources.debian.net/src/openssh/1:6.7p1-3/debian/patches/debian-config.patch/
>
> which includes mention of the fact that the change was introduced in
> order to close this bug:
>
>   https://bugs.debian.org/237021
>
> where Colin states in  Message #47:
>
>   I think it's become clear that it's too far-reaching at this point in
>   Debian's release cycle; we need time to prepare the rest of the
>   distribution for this sort of thing if it's to become the default.
>
> That was in 2004 while Sarge was (not) getting released -- we've had
> 5 complete release cycles since then, so it might be time to get rid of
> this patch.

I agree that this certainly needs better documentation, and I'll fix
that up.  Apologies for not having done that sooner.

I tried some experiments with ForwardX11Trusted=no today, and frankly,
it doesn't even pass the laugh test for usability.  Run xterm and try to
select something, bam, your xterm crashes with BadAccess.  Now, sure,
that's telling me that the X SECURITY extension forbids writing to the
selection, but giving client software a chance to catch up with the
expectation that it should handle such errors is exactly the kind of
reason that I chose to deviate from the upstream default in the first
place!  Now, I didn't do very exhaustive testing or anything, but to me,
those ten years haven't actually made a perceptible difference to how X
clients respond to failures from the SECURITY extension.

If I thought that this was actually useful, it might be worth the pain.
But at least I'm not the only one who thinks that this is a dubious
benefit for the pain it brings:

  https://cygwin.com/ml/cygwin-xfree/2008-11/msg00154.html

So: I don't think that this decision is realistically just up to me.  If
I change ssh back to use ForwardX11Trusted=no by default, a bunch of
other maintainers are going to be asked to fix their software in various
ways: the SECURITY extension may say no to something, but you might
reasonably expect that double-clicking in your terminal won't make it
explode in your face.  

debian-devel, debian-x, do you think that it's at all realistic to
expect clients to be fixed to handle such failures rather more
gracefully?

--
Colin Watson                                       [[hidden email]]

Reply | Threaded
Open this post in threaded view
|

Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Josselin Mouette
Le mercredi 19 août 2015 à 20:59 +0100, Colin Watson a écrit :
> debian-devel, debian-x, do you think that it's at all realistic to
> expect clients to be fixed to handle such failures rather more
> gracefully?

Well, I guess it is possible, if we were to introduce appropriate error
checking in enough major toolkits.

At least in GTK3, I can tell you that it’s not here, and using untrusted
cookies will quickly make your applications crash.

--
 .''`.      Josselin Mouette
: :' :
`. `'
  `-

Reply | Threaded
Open this post in threaded view
|

Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Christoph Anton Mitterer-2
In reply to this post by Colin Watson
On Wed, 2015-08-19 at 20:59 +0100, Colin Watson wrote:
> I tried some experiments with ForwardX11Trusted=no today, and
> frankly,
> it doesn't even pass the laugh test for usability.

Well but it's ssh "Secure Shell" - and not ush (Usability Shell).
So the defaults should be always the secure ones, and not the fancy-out
-of-the-box™. :-)

I don't mind though, to leave the defaults as is in stable.


> Run xterm and try to
> select something, bam, your xterm crashes with BadAccess.

Which means that people would typically note quite quickly that they
need to open up things more (if they want to continue).

In my opinion this is much less worse, than having the current default,
where people who may be at risk wouldn't notice anything.


> Now, I didn't do very exhaustive testing or anything, but to
> me,
> those ten years haven't actually made a perceptible difference to how
> X
> clients respond to failures from the SECURITY extension.

But just because clients are broken (in that respect) doesn't justify
to "work around" their issues, by making things in ssh less secure.


> So: I don't think that this decision is realistically just up to me.
> If
> I change ssh back to use ForwardX11Trusted=no by default, a bunch of
> other maintainers are going to be asked to fix their software in
> various
> ways: the SECURITY extension may say no to something, but you might
> reasonably expect that double-clicking in your terminal won't make it
> explode in your face.

Fixing all clients is probably unrealistic,... but anyway, the choice
should be in the hands of the sysadmin. X forwarding is probably anyway
a rather insecure thing (whether ForwardX11Trusted is yes or no). IMHO
it should generally not be enabled per default.

Having ForwardX11Trusted=no may be enough for many clients people would
use (e.g. such which just display stuff?),... and it's the secure and
expected default for those that read the manpage (but not necessarily
the Debian-modified manpage).


Cheers,
Chris.

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Colin Watson
On Wed, Aug 19, 2015 at 11:51:36PM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2015-08-19 at 20:59 +0100, Colin Watson wrote:
> > Run xterm and try to select something, bam, your xterm crashes with
> > BadAccess.
>
> Which means that people would typically note quite quickly that they
> need to open up things more (if they want to continue).
>
> In my opinion this is much less worse, than having the current default,
> where people who may be at risk wouldn't notice anything.

So the result is that each user of X11 forwarding swears at their
computer for a while until they work out what the problem is, and then
configure "ForwardX11Trusted no" so that it goes away.  I hardly see
this as a net improvement in the state of the world.

I would welcome comments from people other than Christoph, whose views I
am already quite familiar with.  (And thanks, Josselin.)

--
Colin Watson                                       [[hidden email]]

Reply | Threaded
Open this post in threaded view
|

Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Russ Allbery-2
In reply to this post by Colin Watson
Colin Watson <[hidden email]> writes:

> I tried some experiments with ForwardX11Trusted=no today, and frankly,
> it doesn't even pass the laugh test for usability.  Run xterm and try to
> select something, bam, your xterm crashes with BadAccess.  Now, sure,
> that's telling me that the X SECURITY extension forbids writing to the
> selection, but giving client software a chance to catch up with the
> expectation that it should handle such errors is exactly the kind of
> reason that I chose to deviate from the upstream default in the first
> place!  Now, I didn't do very exhaustive testing or anything, but to me,
> those ten years haven't actually made a perceptible difference to how X
> clients respond to failures from the SECURITY extension.

> If I thought that this was actually useful, it might be worth the pain.
> But at least I'm not the only one who thinks that this is a dubious
> benefit for the pain it brings:

>   https://cygwin.com/ml/cygwin-xfree/2008-11/msg00154.html

> So: I don't think that this decision is realistically just up to me.  If
> I change ssh back to use ForwardX11Trusted=no by default, a bunch of
> other maintainers are going to be asked to fix their software in various
> ways: the SECURITY extension may say no to something, but you might
> reasonably expect that double-clicking in your terminal won't make it
> explode in your face.

Yeah, I think I agree.

It would be great if X supported two different types of X forwarding:
trusted and untrusted, with apps working in untrusted mode but with more
restricted privileges.  Should that ever become the case, that would be a
great feature to enable.

However, right now, there are two different types of X forwarding: the one
that works, and the one that causes X apps to crash randomly.  Or, in
other words, "doesn't work."  If you want X forwarding that doesn't
actually work, just don't use the -X or -Y option at all, and you'll have
a much better error message.

If someone felt excited about doing the work required to make this feature
usable, it sounds like there's lots of low-hanging fruit in the form of X
programs that could be taught to support the X11 SECURITY extension.

In the meantime, everyone uses ssh -X to forward an X connection that will
actually work, and has adjusted to the fact that this grants a lot of
power to the remote system.  (I've been hearing warnings about being very
careful with what hosts you use -X with for something like 15 years.  It's
not old news.)  I've rarely met someone who even knew -Y existed, let
alone used it.

If there were a real feature benefit, the backwards-incompatibility may be
worth it, but given that the feature doesn't actually work, meh.  It's
hard to get particularly excited about doing work to try to enable it, and
it feels really dubious to do it by breaking the command-line option
everyone is used to using.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>