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

[Karsten M. Self]

on Fri, Mar 18, 2005 at 06:08:04PM -0800, Richard Harke (rharke at 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. 

> 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
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:

3:  'sux <commmand>'

4:  (su|sudo to root) 
    export DISPLAY=<display>; 
    xauth merge ~<USER>/.xauthority; command

5:  ssh -X root at 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.

-- 
Karsten M. Self <kmself at ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Music makes one feel so romantic - at least it always gets on one's
    nerves - which is the same thing nowadays.
    - Oscar Wilde
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://ns1.livepenguin.com/pipermail/vox-tech/attachments/20050318/7781a8f9/attachment.bin