l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
October 20: Web Application Hacking: How to Make and Break Security on the Web
Next Installfest:
TBD
Latest News:
Oct. 10: LUGOD Installfests coming again soon
Page last updated:
2005 Mar 19 09:51

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] xhost+: Why you should NEVER DO THAT



On Friday 18 March 2005 19:37, Karsten M. Self wrote:
> on Fri, Mar 18, 2005 at 06:08:04PM -0800, Richard Harke 
(rharke@earthlink.net) wrote:
> > On Friday 18 March 2005 16:12, Karsten M. Self wrote:
> > > The history of secure applications development is largely divided into
> > > two groups:
> > >
> > >  1. Those who anticipate hostile environments, design for scenarios in
> > >     which no two components trust one another, and correctly implement
> > >     failsafe, trust, integrity, and encryption procedures.
> > >
> > >  2. Those who've been the source of multiple compromises.
> > >
> > >
> > > Paranoia pays off here.  Safe practices pay off.  Even those who _are_
> > > paranoid and cautious suffer breakins (the good ones will let you know
> > > that this has happened).  The truely frightening are those who deny the
> > > problem exists _and_ fail to recongize a compromise when they see it.
> >
> > When I first installed firefox it refused to run.
>
> You don't provide any specifics on the problem or why it refused to run.
>
> Nor is there a record of your encountering this problem on the LUGoD
> lists or in Google (based on your first+last name and keyword
> 'firefox').
>
> I'm going to presume this was Firefox 0.9.x and your problem is similar to
> that described here:
>
>     http://lists.suse.com/archive/suse-kde/2004-Aug/0122.html
>
> Specifically quoting a readme file:
>
>     Because of missing registration features in firefox 0.9.x you have
>     to start firefox as root the first time after installation.
>
>     If you get a message like
>     -----8<------------------snip--------------8<--------------
>     Xlib: connection to ":0.0" refused by server
>     Xlib: XDM authorization key matches an existing client!
>     ----->8------------------snap-------------->8--------------
>
>     you have to disable the X authorization with command
>     'xhost +' and startup firefox.
>     After the initial startup you can close your X session
>     again by 'xhost -' and you should be able to start firefox
>     from now on without problems.
>
This is in fact the problem I had. I never saw the readme though and
never did try to start firefox as root. After xhost + I could start
firefox as a user but after I did xhost -, it would not start. This has 
changed since I did the update. That is, it refused to run. I did xhost +
It would run. I did xhost - and it still runs. I still have not run it as
root.
My first installation was some time after version 1.0 was announced
but I didn't check the version at debian.
> > After googling about I found the advice to do xhost +.
>
> Best I can tell (I don't have the broken Firefox build on my system, and
> never encountered it), so this is based on general experience:
>
>   - The xhost advice is unnecessary.  The alternative I've mentioned in
>     this discussion -- running 'sux' or as root setting $DISPLAY and
>     merging the user's ~/.xauthority file -- would be sufficient.
>     'xhost +' is faster and easier, but remains bad advice.  I'm not
>     sure if SuSE ships with 'sux', but tool ommissions in other areas on
>     a recent SuSE 9.1 build don't impress me.
>
>   - This is a fix which is local to the system at hand.  'xhost +
>     localhost' would probably also have worked, and would have _not_
>     dropped all access security to your X display.
>
>   - On a sanely configured X server, not listening to external TCP
>     traffic, even running 'xhost +' would not open you up to external
>     hosts, due to your server settings.  This is where Mark Kim's advice
>     is mind-bogglingly inappropriate:  not only is it overtly harmful
>     (in the event of a misconfigured X server), but (in the case of a
>     correctly configured one) it fails to address the problem at hand.
>
> Incidentally, if your X server _is_ listening to external TCPIP traffic,
> and you haven't explicitly configured it to do so yourself, you _should_
> write file a bug report.
>
> > Based on this thread I should have rejected the advice leaving me with
> > two alternatives:
> >
> > 1:   download the firefox source and debug it.
>
> That's your prerogative, and I'm sure the Firefox team would have
> appreciated your contribution.
>
> > 2:   apt-get purge firefox  (followed by a nasty email to somewhere)
>
> While I suspect there's a hint of tongue-in-cheek in your response, that
You're right
> would have been _fully_ appropriate.  Firefox shipped with a broken
> config (as noted in the README fragment quoted in the post referenced
> above), and supplied a workaround which is dangerous and highly
> questionable.
>
> You are, however, ommitting the several options available to you for
> running X applications as root which _don't_ involve inviting the world
> to your desktop:
As noted above, I didn't think about running firefox as root. Also, I have my 
system configured so I startx as a user after I login so I'm not sure how
the firefox readme would apply. (I assume most users have X started by
root immediately after booting up)
>
> 3:  'sux <commmand>'
>
> 4:  (su|sudo to root)
>     export DISPLAY=<display>;
>     xauth merge ~<USER>/.xauthority; command
>
> 5:  ssh -X root@localhost
>
>
> Note that 4 and 5 raise additional issues,  I'd deprecate 'su' in favor
> of 'sudo' as a general rule, and disallow remote root logins.  On a
> single-user system these are less aggregious than the 'xhost +' inanity,
> but should still be avoided if at all possible (and it most definitely
> _is_ at all possible).  In balance, 'sux' is probably the best mix of
> sufficient (fixes the immediate problem), safe, and simple.
>
> Good security practices are in very large part a matter of making an
> explicit effort to Do The Right Thing[tm] whenever possible.  It keeps
> you out of bad habits.  Being overtly secure when you don't absolutely
> have to be (personal system, home LAN, trusted network) means that
> you'll be doing the right thing, by habit, when it _does_ matter.
>
>
> Peace.
Thanks for the explanations, I have learned a lot.
I guess I should have posted the problem here in the first place.
Richard
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.