Re: X forwarding

[nisse%lysator.liu.se@localhost (Niels Möller)]

der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> writes:

> I can see no value whatever in making the client pass an X
> authentication method and data blob to the server.

The only value I see is that the munging of the X-protocol data
stream, and the "fake cookie"-handling, is moved to the client rather
than the server. When having the choice, I often prefer a complex
client over a complex server. Besides that, I agree with what you're
saying.

> > In more general terms, letting the server do the authentication is in
> > a way making an (X11) client responsible for X11 server security,
> > which is not good practice.
> 
> I don't understand the point here.  I have been unable to come up with
> a threat model against which having the client provide an
> authentication method and data blob provides any defense.  My other
> question: can anyone give an example?

Maybe not a good example, but I think you may failure mode when
talking to a server that doesn't do any authentication at all (it just
binds a tcp socket and starts forwarding connections). If the client
expects a cookie in the ssh channel, it will reject unathorized
connections.

Including the cookie will of course not provide any protection from an
compromised server (say, it opens a tcp socket and forwards it, and in
addition stores the supplied cookie somewhere where the attacker can
read it).

But I think it may provide some protection from servers that are
misconfigured rather than compromised. I agree all this is a pretty
weak argument.

> I'm implementing X forwarding as a private request which carries only a
> uint32 cookie and a screen number; when the server wants to forward an
> X connection, the channel open carries the cookie and the first six
> bytes of the X protocol stream sent by the client (I could have sent
> these as the first data on the new connection, but this way seems
> marginally simpler).

Please write up a spec for this.

Including details such as the expectation that the server will ensure
(by creating a new random cookie, or by some *stronger* authentication
method) that only authorized processes can use the X forwarding. And
in which way the forwarding is associated to a session (for example,
if the forwarding is cancelled automatically when the session channel
is closed).

The lack of a display id is one of the reasons my "connection sharing
thing", lshg, doesn't support X11 forwarding, so I may want to use
your new request type.

Regards,
/Niels