Date: Wed, 21 Mar 2001 11:51:27 -0800 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: David Pick <D.M.Pick@qmw.ac.uk> Cc: security@FreeBSD.ORG Subject: Re: Disabling xhost(1) Access Control Message-ID: <200103211952.f2LJqAi08753@cwsys.cwsent.com> In-Reply-To: Your message of "Wed, 21 Mar 2001 17:54:57 GMT." <E14fmoz-0001CG-00@xi.css.qmw.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <E14fmoz-0001CG-00@xi.css.qmw.ac.uk>, David Pick writes: > > > I also think about disabling xhost and wonder which solution have you > > chosen -- modifying Xserver source offered later in the thread? Actually, > > "-nolisten tcp" is a nice idea, but I would like X to run from the server > > on all "Xterminals", and of course "X -query" fails that way... > > I actually run two copies of "xdm": one (with "-nolisten tcp") for the > local display which also has the XDMCP port set to zero to disable > remore X displays using XDMCP; and the other copy of "xdm" with no > X servers at all, just listening for XDMCP on port 177. > > Makes it much easier to control the availability of XMDCP without > editing files as such. I use this on a laptop which wants just the > local display in most connections, but I want to allow the use of > an X terminal when I'm at home with a trusted desktop and 17" monitor. I use a locally modified version of Xforward (ftp://crl.dec.com:/pub/DEC /xforward.tar.Z). Xforward is designed to proxy X sessions through a firewall. Before proxying a session (allowing the connection), it will pop up a window asking whether the connection should be allowed. I can click on "Yes" or "No" to allow/disallow the connection. I then block all access to my X server's port (6000) using IP Filter or IPFW, only allowing Xforward running on my desktop to talk to port 6000. The drawback to Xforward is that it does not support MIT cookies or any other authentication mechanism, so xhost <local_hostname> must be done. This is a problem on multi-user systems, however personal desktop systems, e.g. my workstation, where I am the only user using (or allowed to use) the system, this is not a problem, as the firewall will protect the perimeter. This breaks the concept of security through depth, however when running remote X clients, this is probably the lesser of the two evils. Xroute, another X proxy, can be manipulated to do the same. I'm not sure where I got Xroute from. Creation of Xforward and Xroute ports for the ports collection are in my queue of things to get done, so you should see them shortly (after I've completed the Tripwire 2.3.1 port). Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103211952.f2LJqAi08753>