morreale@bierstadt.scd.ucar.edu (Peter Morreale) (10/29/90)
Hopefully a simple question.....
I'm trying to figger-out how I can lock my server against unauthorized
use on a *user* basis. Locking out a host is easy, but can I
allow access from a specific logon on a host?
X(1) and xauth(1) seem to imply that you can, however I see no provision
(in xauth) to allow say joe@foo.bar to connect to smith's server on
foobar.bar.
What am I missing? Can someone explain how? (if it is possible...)
(BTW: Thanks to the netters who made things like "scrawl" and "xufo"
available to the students of the world.... ;-)
Best,
-PWM
------------------------------------------------------------------
Peter W. Morreale email: morreale@ncar.ucar.edu
Nat'l Center for Atmos Research voice: (303) 497-1293
Scientific Computing Division
Consulting Office
------------------------------------------------------------------barmar@THINK.COM (Barry Margolin) (10/30/90)
In article <8974@ncar.ucar.edu> you write: >Hopefully a simple question..... No such thing when X is involved. :-) >I'm trying to figger-out how I can lock my server against unauthorized >use on a *user* basis. Locking out a host is easy, but can I >allow access from a specific logon on a host? You can't do this in general, because user names aren't passed in the X connection request. And even if user names were passed, you'd need an additional mechanism (such as prompting for a password, or using an authentication system such as Kerberos) to verify the user's identity. >X(1) and xauth(1) seem to imply that you can, however I see no provision >(in xauth) to allow say joe@foo.bar to connect to smith's server on >foobar.bar. That's not what I infer from the xauth documentation. The access control that xdm and xauth implement is based on the server being given a random number (the "magic cookie") by xdm and only accepting connections from clients that know the magic cookie. Xdm also writes the magic cookie into a file (the value of the env variable XAUTHORITY, usually ~/.Xauthority), and clients run by the user can get the magic cookie from this file. So long as the file is only readable by the user, only he can access the display. >What am I missing? Can someone explain how? (if it is possible...) Here's how Smith can use this facility to allow joe@foo.bar to connect to his display. After logging in with xdm he can use xauth to copy the magic cookie for his display into a file that joe@foo.bar can read. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
schoch@trident.arc.nasa.gov (Steve Schoch) (10/31/90)
In article <8974@ncar.ucar.edu>, morreale@bierstadt.scd.ucar.edu (Peter Morreale) writes: |> I'm trying to figger-out how I can lock my server against unauthorized |> use on a *user* basis. Locking out a host is easy, but can I |> allow access from a specific logon on a host? When you get a list of host that are allowed to connect by running "xhost" with no arguments, this shows you the list of hosts from which ANYBODY can connect to your server. xauth allows a client to connect to your server whether it is listed in the xhost list or not. For instance, I use xauth on my server. When I type xhost, it show me this: sheba 52% xhost access control enabled (only the following hosts are allowed) sheba 53% In other words, NO hosts are allowed to connect to my server (without X authorization). |> X(1) and xauth(1) seem to imply that you can, however I see no provision |> (in xauth) to allow say joe@foo.bar to connect to smith's server on |> foobar.bar. It doesn't work that way. I assume you are using the R4 xdm. Make sure you have a line in xdm-config such as this: DisplayManager*authFile: /var/adm/xdm/auth-server and make sure the directory exists where auth-server is supposed to go. The way it works is this: (assuming it is using the MIT-MAGIC-COOKIE-1 authorization scheme) 1. xdm randomly generates a "magic cookie" (a 16-byte random number). 2. xdm puts this number in the "authFile" mentioned above. 3. It starts (or restarts) the server with the argument "-auth /var/adm/xdm/auth-server". 4. X (the server) reads the magic cookie and then removes the file (for security). 5. Using the magic cookie to authorize itself, xdm brings up the login window. 6. When you login, xdm puts the magic cookie in a file called ".Xauthority" in your home directory. 7. Clients read this file and send the cookie to the server upon first connecting. If the cookie matches the one that was given to the server by xdm, the connection is authorized whether the client is running on an authorized host or not. The xauth(1) program is used to read entries from the ".Xauthority" file. Using xauth, you can transfer a cookie to a remote machine with a command such as: % xauth extract - $DISPLAY | rsh remote -l user xauth merge - Or, you could use the "nextract" command to mail the cookie to another use who could then bring up a window on your server. The cookie is good until the end of the session when xdm generates another cookie to give to the server. Steve
barmar@think.com (Barry Margolin) (10/31/90)
In article <1990Oct30.205926.28985@news.arc.nasa.gov> schoch@trident.arc.nasa.gov (Steve Schoch) writes: > 3. It starts (or restarts) the server with the argument >"-auth /var/adm/xdm/auth-server". Does this mean that MIT-MAGIC-COOKIE-1 authorization can only be used when the server is running on the same host as xdm? What is done for X terminals and other random X servers? -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
keith@EXPO.LCS.MIT.EDU (Keith Packard) (11/01/90)
> Does this mean that MIT-MAGIC-COOKIE-1 authorization can only be used when > the server is running on the same host as xdm? What is done for X > terminals and other random X servers? When the X terminal is controlled by XDMCP (as most should be), xdm is willing to generate authorization keys for use by the session. The recent Tektronix terminals support MIT-MAGIC-COOKIE-1 authorization, which surprised me quite a bit. I just plugged it in and it worked. Other terminal vendors will be providing this as well, sooner if you clamour loudly for it. If you're still running xinit, you can set up an authorization file and type in your own cookie and tell the X server to use that file for authorization information, using the -auth option to the server (which is how xdm transmits the cookie to local servers now). From the look of things today export-law wise, we'll be able to also provide XDM-AUTHENTICATION-1/XDM-AUTHORIZATION-1 as well, giving you a system which doesn't depend on the security of the underlying transport for secure authorization. I think we'll also see kerberos (or other network authentication systems) schemes which will help resolve the issues of per-user access control and key dissemination.
schoch@sheba.arc.nasa.gov (Steve Schoch) (11/02/90)
In article <1990Oct31.000115.26078@Think.COM>, barmar@think.com (Barry Margolin) writes: |> Does this mean that MIT-MAGIC-COOKIE-1 authorization can only be used when |> the server is running on the same host as xdm? What is done for X |> terminals and other random X servers? An X terminal will get the authorization scheme and the authorization data (the cookie) from xdm on a remote host using XDMCP (X Display Manager Control Protocol?). As part of the XDMCP handshaking, the server will tell xdm which authorization schemes it supports and then xdm will tell the display which one to use (obviously both the server and xdm must support it) and the data to use with it. I found this by reading the source, but the information is also availiable in mit/doc/XDMCP. Steve