Re: New Proposal for Section 11.3.3 X11 Forwarding

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Thu, May 15, 2003 at 08:42:33AM -0700, Chris Lonvick wrote:
> Should this proposal entirely replace the prior proposal or are there
> parts of the prior proposal that should be kept with this?  I appreciate
> the suggestions you've made here.

How about this (my proposed text added between the first and second
paragraphs you proposed):

11.3.3 X11 Forwarding

   Another form of proxy forwarding provided by the ssh connection
   protocol is the forwarding of the X11 protocol.  If end-point
   security server.  Users and administrators should, as a matter of
   course, use all available X11 security mechanisms to prevent
   unauthorized use of the X11 server.  Implementors, administrators and
   users who wish to further explore the security mechanisms of X11 are
   invited to read [SCHEIFLER] and analyze previously reported problems
   with the interactions between SSH forwarding and X11 in CERT
   vulnerabilities VU#363181 and VU#118892 [CERT].  Additionally, they
   are advised to review the problems found and the lessons learned in a
   paper by Wietse Venema [Venema] presented to the 6th USENIX Security
   Symposium.

   X11 display forwarding, by itself, is not sufficient to correct well
   known problems with X11 security [Venema].  However, X11 display
   forwarding in SSHv2 (or other, secure protocols), combined with
   X11 actual and pseudo-displays which accept connections only over
   local IPC mechanisms authorized by file permissions or other ACLs,
   does correct many X11 security problems.  It is RECOMMENDED that X11
   display implementations default to allowing display opens only over
   local IPC.  It is RECOMMENDED that SSHv2 server implementations that
   support X11 forwarding default to allowing display opens only over
   local IPC.  On single-user systems it may be reasonable to default to
   allowing local display opens over.

   Implementors of the X11 forwarding protocol SHOULD implement the
   magic cookie access checking spoofing mechanism as described in
   [ssh-connect] as an additional mechanism to prevent unauthorized use
   of the proxy.

   [references]

Cheers,

Nico
--