I think it'd be a lot nicer to put this in /etc/sysconfig/ or some other 
global place, so the same setting controls startx and so forth.

No opinion on whether it's the right change or not. I don't think X has had a
remote exploit in a very long time, has it?

*** Bug 98697 has been marked as a duplicate of this bug. ***

Well, putting it in /etc/sysconfig and reading it in xinitrc could work, I
suppose, as long as it's well documented. But it's definitely a behavioral change.

Seems like it would generate a fair amount of "why can't I connect to my X
server" type of email.

It'd be nicer if X could dynamically toggle whether it's listening, so you don't
have to log out and back in to enable it.

Like I said, I don't have any figures, but your scenario seems much more
unlikely than mine.

An user who knows that he can use X remotely is already a relatively rare one.
From those, I'd guess that the vast majority doesn't even know how to manage it,
but only uses it since it has been configured by a sysadmin.
Sysadmins who won't be able to put it back without whining like you fear,
deserve to be h4x0r3d ;)

Ergo,  that fair amount doesn't seem that fair to me.

The proposed config that I defined in bugzilla.gnome.org makes the change to
export as hard as changing a simple line by providing two X server options but
using the safest one by default.

And yes, it would be nicer if X did that dynamically, but it doesn't and this is
a potential security risk that's easily checked out with minor inconveniences.

We should never ship with "-nolisten tcp" in the command line IMO.  In the cvs
gdm (and thus in gnome 2.4) there is a DisableTCP=true flag (true by default),
that automatically adds "-nolisten tcp" to command lines (only where appropriate,
that is where tcp is really not needed).  I was always kind of conflicted about
this anyway.  While yes it is as simple as changing a config file to turn it on.
 It will suddenly stop working for you and it won't tell you what config file to
change.  The DisableTCP at least puts this option into the GUI to make it easier
to find.  However it still sucks.  I would really like some way of finding this
out from the system config, perhaps the DisableTCP could have more then 2
values, and have something like DisableTCP=check-sysconfig

One saving grace of this change is that ssh properly tunnels the protocol and so
even with -nolisten tcp, this still works.

However, I'd advise against adding '-nolisten tcp' to the config and just wait
for gnome 2.4 and use DisableTCP=true if this is wanted.  I really don't think
this is a big security thing either.  A home machine should be properly
firewalled and you could just block the X tcp ports on install.

Yes, home boxes should be firewalled and no, they quite rarely are. 
Yes, there is no known security holes in X and that really tells us nothing
about those hiding security holes. :)

When RH is installed with default settings as a workstation of a clueless
end-user, the box should not listen to any ports by default. As it was said, if
the user knows about remote X, he's clueful enough to enable it.

If this is considered a GDM thing, the logical place in UI to enable remote X
would be under Gnome's GDM Setup -> Security. Otherwise /etc/sysconfig/ sounds
good. :)

I would very very very much like to avoid dumping more files into
/etc/sysconfig which are OS and distro independant.  I think the proper fix
is for the application which is actually starting X up, to pass it the
correct options and to store those settings in it's own config file(s).

How that is done I don't think matters much, but I think /etc/sysconfig
is an ugly hack way of working around it.  I'd like to see it done by
gdm/kdm/whatever itself.  It then also is portable to non-Linux, and to
non-Red Hat OS's so everyone benefits.

I think we need to look beyond solving problems in an OS specific way
as often as possible where it can be done without difficulty, and to
avoid adding ugliness.

Oops, hit submit too soon.

... and since it is allegedly in gdm CVS as noted above...  we should backport
that to our current stuff and get the fix for almost free.

Someone (than?) should check kdm as well.

(personally, I think the X server should disallow TCP by default internally
 unless it is enabled in the _config_ file... but that's just me....  <grin>)

So if you get all the X scripts upstream, you can upstream this setting. ;-)
Plus we'll have a less annoying X package. Win all around! ;-)

It should be an X server setting, not a login manager setting.

While it is not corrected upstream something should be done. Lot's of RedHat
packages have patches to improve things that are either not yet upstream or
backporting upstream stuff.

Please don't use the "upstream" excuse to avoid doing a simple thing that will
close down a potential security risk.

hp:  I don't disagree, at least in theory.  If it is possible to be a config
file setting, I think it should be one that is available to use, yes.  The
X transports should be initialized after the config file is parsed, so it should
be possible.  The problem however, is then our 4.3.0 X server contains a config
file option that isn't understood by stock 4.3.0, and possibly not by any
XFree86.org server, more importantly - not understood by any X server we've
ever shipped before.  So this really is something that should be agreed to by
upstream before implementation IMHO.  Implementation I would assume would be
trivial, probably less than a dozen or so lines of code.

If I become the one to implement it, I'd like to leave it for post-4.3.0
however, or else we will likely have some compatibility issues to deal with
across all of our 4.3.0 supported platforms which I'd rather avoid.

I discussed it with Keith, and he seems to agree with my idea, also extending
it to allow the disabling of more than one transport.  Keith thinks that
it might be a good idea to have it disable TCP by default.  This also implies
that we'd need a counter option to enable disabled transports, and both on
the commandline and the config file.

I think it would be fairly trivial to implement all of this for 4.4.0.  That
doesn't resolve this for RHL 8.0 or 9 however.  Since X, as shipped doesn't have
the above described solution in it, it'll have to be implemented in gdm et al.
if we decide to disable TCP in 8.0/9 in future erratum.  That is for you guys
to decide however.

How does this sound?

I think that Mike's right. However, priority should be given on fixing this for
next release; since there is no known exploitable hole right now there isn't an
urgency in fixing it for RH8 or RH9 just because of that, one can wait for
another XFree86 update (if it happens).

The risk is there already and has been for some time. The harm hasn't come yet
so I think that one can consider having it fixed (even if in an intermediate
temporary fashion) for next release of gdm, kdm, xdm, RH, XFree86 et all.

Absolutely.  X is far from what I would bet my front teeth on as being secure.
One look through the sources and you'll find tonnes of potential surprises here
and there.  Wether any are exploitable, requires someone to actually investigate
the shady areas more deeply.  Wether that is some leet cracker out there or
someone auditing X and fixing it, remains to be seen.

My money is on Joe leet doing a remote exploit before someone knows it exists.
I'm sure if we needed a useable example, Al Viro could find a hole in less than
a half hour.  ;o)

hmm, did something happen to this after all?

gdm/kdm/xdm should all start X with -nolisten tcp by default now
for quite a while.  I still plan on disabling the tcp transport
directly in the X server by default in the future however, and
requiring the user to -listen tcp to enable it.  Upstream X
developers share this sentiment, so this may actually occur
upstream in the future.