Re: Disabling xhost(1) Access Control
From: Cy Schubert - ITSD Open Systems Group (Cy.Schubert@uumail.gov.bc.ca)
Date: 03/21/01
- Next message: Larry Librettez: "Cannot su to root in X terminal with 4.3-BETA"
- Previous message: itojun@iijlab.net: "Re: IPSEC/VPN/NAT and filtering"
- In reply to: David Pick: "Re: Disabling xhost(1) Access Control"
- Next in thread: Alexey Koptsevich: "Re: Disabling xhost(1) Access Control"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: David Pick <D.M.Pick@qmw.ac.uk> Date: Wed, 21 Mar 2001 11:51:27 -0800
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
- Next message: Larry Librettez: "Cannot su to root in X terminal with 4.3-BETA"
- Previous message: itojun@iijlab.net: "Re: IPSEC/VPN/NAT and filtering"
- In reply to: David Pick: "Re: Disabling xhost(1) Access Control"
- Next in thread: Alexey Koptsevich: "Re: Disabling xhost(1) Access Control"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|