[17904] in Athena Bugs
Re: sun4 8.3.29: X
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Jun 13 22:05:17 2000
Message-Id: <200006140205.WAA19645@small-gods.mit.edu>
To: John Hawkinson <jhawk@MIT.EDU>
cc: amu@MIT.EDU (Aaron M. Ucko), bugs@MIT.EDU
In-Reply-To: Your message of "Tue, 13 Jun 2000 21:59:32 EDT."
<200006140159.VAA13354@bobbi-harlow.mit.edu>
Date: Tue, 13 Jun 2000 22:05:13 -0400
From: Greg Hudson <ghudson@MIT.EDU>
> Is this a problem? Doesn't MIT-MAGIC-COOKIE also restrict
> connections by ip address, too?
No. Either you restrict connections by IP address or you do it by one
of the provided security schemes, not both. And there's no way to get
the X server to only listen on a Unix domain socket. It's a pretty
sad state of affairs.
As Athena currently has things configured, you at least have to
connect from 127.0.0.1 or a local interface address, which is probably
a reasonable barrier to outside attacks. (Unless our machines and X
servers are vulnerable to a source-routing attack which would make it
trivial to forge connections from 127.0.0.1... I don't know of a
sufficiently easy way to test that.) If we went with
MIT-MAGIC-COOKIE, we would have to worry about the cookie not being
secret enough to prevent attacks from random parties on the net.
I might consider enabling magic cookie authentication on platforms
with /dev/random (i.e. Linux, right now, I think). Enabling it on
Suns with keytabs using the keytab as a random seed might be
reasonable, but it would expose the keytab if the one-way hash
function is too weak, so I'm not too keen on that.
