Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!bucsb!jbw
From: jbw@bucsb.UUCP (jbw)
Newsgroups: comp.windows.x
Subject: Re: X11R3 security hole needs attention
Summary: inews garbage
Message-ID: <2418@bucsb.UUCP>
Date: 24 Mar 89 19:31:01 GMT
References: <8903172201.AA16819@EXPIRE.LCS.MIT.EDU> <8903172239.AA00594@buit5.bu.edu> <848@share.ursa.UUCP>
Reply-To: jbw@bucsf.bu.edu (Joe Wells)
Followup-To: comp.windows.x
Organization: Boston Univ Comp. Sci.
Lines: 31

In article <848@share.ursa.UUCP> jmd@share.UUCP (Josh Diamond) writes:
>In article <8903172239.AA00594@buit5.bu.edu> jsol@BU-IT.BU.EDU writes:
>>Is there anything we can do to alleviate the problem? 
>
>     At this point in time, not much, other than using xhost to turn off
>all access to the display (including from the local host).  The security
>hole becomes smaller if you only xhost + a host long enough to bring up the
>window, and then xhost - it again once the widow is up.  This seems to work
>well for me.

Unfortunately, turning off local access to the server with xhost will
prevent any new connections from being accepted, including from xhost.
Thus, once taken away, the ability to run local X clients can not be
restored.

However, turning off local access (to other users) is what is needed.
These workstations are being used as multiuser machines.  In addition
to the user on the console, people who need to work on a Sun
architecture log in remotely.  The actual setup is this: any login
attempt to the server from the campus network is rerouted to one of
the workstations.  The belief is that better performance will be
achieved by keeping interactive users off the file server.

It can be interesting when 3 or 4 people are running GNU Emacs on a
Sun 3/50 workstation.  Interactive response on the console tends to be
a little slow ...

--
Joe Wells
INTERNET: jbw%bucsf.bu.edu@bu-it.bu.edu    IP: [128.197.10.201]
UUCP: ...!harvard!bu-cs!bucsf!jbw