[17905] in Athena Bugs
Re: sun4 8.3.29: X
daemon@ATHENA.MIT.EDU (John Hawkinson)
Tue Jun 13 23:08:26 2000
Date: Tue, 13 Jun 2000 23:08:20 -0400 (EDT)
Message-Id: <200006140308.XAA14551@contents-vnder-pressvre.mit.edu>
To: Greg Hudson <ghudson@mit.edu>
CC: amu@mit.edu (Aaron M. Ucko), bugs@mit.edu
In-reply-to: "[17904] in Athena Bugs"
From: John Hawkinson <jhawk@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.
I think this isn't quite right, but what I said isn't right either.
If you have X authorization enabled (MIT-MAGIC-COOKIE,
XDM-AUTHORZATION-1, SUN-DES-1, whatever), then X will allow you to
remove localhost and the local interface addresses (and the
unix-domain socket) from the authorization list (Well, strictly
speaking, it always lets you remove them, but adds them back in
later).
I suspect it would be adequate to use a .Xauthority file
with a bogus entry for an unsupported authorization method.
Xsecurity(1) for Solaris, IRIX, and Linux all claim to support
the same set:
systems. The sample implementation includes five mecha-
nisms:
Host Access Simple host-based access control.
MIT-MAGIC-COOKIE-1 Shared plain-text "cookies".
XDM-AUTHORIZATION-1 Secure DES based private-keys.
SUN-DES-1 Based on Sun's secure rpc system.
MIT-KERBEROS-5 Kerberos Version 5 user-to-user.
I dunno how to tell for sure. But it seems likely that at least one
should work. It would be ideal if we could generate a key such that it
could not be used, but would serve to have the server believe that the
it had an authization file and thus allow you to remove the local
interfaces.
--jhawk
