[18545] in Athena Bugs
Re: linux 8.4.17: dm not using xauth
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Nov 27 09:56:36 2000
Message-Id: <200011271456.JAA23092@egyptian-gods.MIT.EDU>
To: Michael P Phillips <mpp@MIT.EDU>
cc: bugs@MIT.EDU
In-Reply-To: Your message of "Mon, 27 Nov 2000 02:00:00 EST."
<200011270700.CAA01925@tiny-tetazoo.mit.edu>
Date: Mon, 27 Nov 2000 09:56:33 -0500
From: Greg Hudson <ghudson@MIT.EDU>
> dm does not use xauth. So, any other users on the same machine can
> manipulate my X display.
This is a frustrating problem and one which can't be solved
satisfactorily because of the stupid security architecture of the X
server. Basically, the X server gives us two choices:
* We can turn on xauth, at which point no IP address checking
is done on the Internet socket, and anyone on the Internet
who can guess the generated secret can get in.
* We can leave xauth off, in which case IP address checking is
done on the Internet socket (which is possibly vulnerable to
source-routing attacks; I've never verified this) but of
course no local access control is done.
What we would like to do is shut off the Internet socket altogether
and use the Unix domain socket, to which access can be controlled
locally. (I'm not sure whether the X server properly controls local
access to the Unix domain socket, but at the moment it's a moot
point.) But there is simply no way to do that at the moment without
compiling our own X servers. You can't even combine IP address
checking and xauth checking on the Internet socket.
Turning on xauth seems superior if we can find a secret which nobody
else can guess--but cluster Sun and SGI machines have no way of
generating secret data. There is nothing unique about them, and their
operating systems don't support /dev/random. The "sane" display
managers you suggested use the system time as the key on those
platforms, leaving themselves open to attack from anywhere on the net.
Linux machines support /dev/random, which is probably good enough
(although it's still a bit questionable whether such idental machines
actually have sufficiently chaotic internal behavior to generate real
entropy), so xauth would probably be satisfactory on that platform.
> Bonus points for Kerb5-based
This can't be done because:
* The native X server binary doesn't come compiled with
Kerberos, and
* Cluster machines don't have keytabs, and can't because they
can't keep secrets from their users.
> IIRC, this has never been done properly. Are we planning on
> abandoning dm or is looking into how to fix this actually worth
> while?
We do not currently have plans to abandon dm. We've found that it's
easier to debug the login sequence if we use our own code for
everything, and while dm has its problems, it's also a lot simpler
than anything else out there. So it would definitely be worthwhile to
add xauth support to dm for platforms which have a functioning
/dev/random.
(Rewriting dm is a definite possibility at some point, incidentally.
It's a short program with a lot of room for improvement. But we don't
have specific plans for that.)
