Hi! Is there any reason why support for the libwrap code isn't included in the X11 forwarding code? I'd like to restrict access to that port. How many applications would break if the tcp port would be closed and only the unix-domain socket would be available? It's true that x11 forwardings can be considered as a security risk and they are disabled because of that by default. I think that the risk can be made (a bit) smaller if there were more controls available to restrict access to the forwarded ports. Another question: is it requirement that the forwarded X11 port is bound to * instead of specific interface? Comments, suggestions? -- Osmo Paananen
On Wed, Nov 14, 2001 at 05:35:21PM +0200, Osmo Paananen wrote:> Is there any reason why support for the libwrap code isn't included > in the X11 forwarding code? I'd like to restrict access to that > port.i think that sshd should not depend on libwrap, it's already the sshd listen port and this is more than enough. having libwrap for other things is a problem because it control system policy instead of user policy. i think x11 fwd should either listen to the localhost or to all interfaces, but with x11/xauth this does not seem to work if DISPLAY points to localhost. i'd prefer to have this fixed. anther dependency on libwrap is a bad idea.> How many applications would break if the tcp port > would be closed and only the unix-domain socket would be available?i don't know. this would be nice. perhaps the x11 proxy code from x11 can give hints.> It's true that x11 forwardings can be considered as a security > risk and they are disabled because of that by default.probably.> I think that the risk can be made (a bit) smaller if there were > more controls available to restrict access to the forwarded ports.but x11 access on this port does not work, because you need the cookie.> Another question: is it requirement that the forwarded X11 port is > bound to * instead of specific interface?xauth does not like DISPLAY=localhost:x.y
On Wed, Nov 14, 2001 at 04:51:14PM +0100, Markus Friedl wrote:> On Wed, Nov 14, 2001 at 05:35:21PM +0200, Osmo Paananen wrote: > > Another question: is it requirement that the forwarded X11 port is > > bound to * instead of specific interface? > > xauth does not like DISPLAY=localhost:x.yHmmm, is it because .Xauthority files are stored in home directories shared across multiple hosts? If so, why not mkstemp() a new .Xauthority file, shove the cookie there and set XAUTHORITY to point to it? Nico -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
On Wed, Nov 14, 2001 at 11:08:04AM -0500, Nicolas Williams wrote:> Hmmm, is it because .Xauthority files are stored in home directories > shared across multiple hosts?have you tried this?> If so, why not mkstemp() a new .Xauthority file, shove the cookie there > and set XAUTHORITY to point to it?have you tried this?
On Wed, Nov 14, 2001 at 05:27:29PM +0100, Markus Friedl wrote:> On Wed, Nov 14, 2001 at 11:08:04AM -0500, Nicolas Williams wrote: > > Hmmm, is it because .Xauthority files are stored in home directories > > shared across multiple hosts? > > have you tried this?Hmmm, not with localhost:*.> > If so, why not mkstemp() a new .Xauthority file, shove the cookie there > > and set XAUTHORITY to point to it? > > have you tried this?Yes. I see. "SecurityBadAuthorizationProtocol (invalid authorization name or data)" Sigh, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
On Wed, 14 Nov 2001, Osmo Paananen wrote: :Is there any reason why support for the libwrap code isn't included :in the X11 forwarding code? I'd like to restrict access to that :port. : :How many applications would break if the tcp port :would be closed and only the unix-domain socket would be available? : :It's true that x11 forwardings can be considered as a security :risk and they are disabled because of that by default. :I think that the risk can be made (a bit) smaller if there were :more controls available to restrict access to the forwarded ports. : :Another question: is it requirement that the forwarded X11 port is :bound to * instead of specific interface? ideally the sshd server x11 socket would be bound to loopback, but there have been issues with different Xlib implementations not using TCP transport and some xauth issues. i believe these issues can be addressed for openbsd and hopefully portable platforms that have a modern X11. i think i have many but not all of the details worked out.