amy@sequent.UUCP (Amy McPharlin) (05/05/90)
I am an engineer at Sequent and am trying to port xdm to run on a
Sequent Symmetry. I am having trouble getting clear-text key-based
security working.
I have xdm running on the Symmetry with the authorize resource set to
true and a protocol of MIT-MAGIC-COOKIE-1. For my display server, I have
the R4 sample server running on a Sun which was invoked with the
command Xsun -query <host machine>.
Xdm and the display server start up and talk to each other fine and xdm
creates an .Xauthority file in the user's account and a file to pass the
key to the server. However I see the following problems:
1. On every session, the same key is generated each time (all f's).
2. The server always refuses access to the clients started by the
user's .xsession. The clients that try to start up are 2 xterms,
an xclock and an xbiff (all versions supplied with the R4 tape).
The error message they get is:
For the first problem, I notice there is a procedure called generateAuth
which looks from the code like it is supposed to generate the cookie.
This procedure, however, is never called by xdm.
Also, this procedure is in a file call xdmauthgen.c which seems to
be a program in its own right. However, I can't find any documentation
on this program nor is it in the xdm Makefile (Imakefile) supplied by
MIT. Does anyone know anything about this program or about the
generateAuth routine?
For the second problem, I'm not sure if the problem is in xdm, the
sample server or in the clients. Can anyone shed some light on this?
Has anyone gotten MIT-MAGIC-COOKIE-1 working? with the sample server?
Has anyone gotten these clients (or any clients) to start up with
security on?
More Security Questions
1. Cookie files
Also, I have some questions about the .Xauthority file and the
file passed to the server with the key. Do both of these files
consist of Xauth records (defined in Xauth.h)? I can look at both
of these files with xauth but I notice xauth only shows display_name
protocol and key. It doesn't show the rest of the fields in Xauth:
family, address, number and their respective lengths. Are these fields
just considered to be not of interest or does xauth show display_name
in lieu of these fields. I can understand what family, address and number
mean in the user's .Xauthority file but what are these fields supposed to
be set to in the file passed to the server? I notice a define in
Xauth.h called FamilyWildcard. Should the family for this file
be FamilyWildcard with the address and number fields just ignored?
2. Clients
What do writers of client programs need to know about security
to make their clients play well with authorization schemes?
I notice the README in the Xau directory seems to be saying
the the client writer doesn't need to do anything - that a
call to XOpenDisplay will take care of everything. Is this true?
Help on any of these issues would be appreciated.
Thanks,
Amy
------------------------
Amy T. McPharlin
User Interface Group
Sequent Computer Systems
15450 SW Koll Parkway
Beaverton, OR 97006
(503) 626-4534
uunet!sequent!amy
------------------------keith@EXPO.LCS.MIT.EDU (Keith Packard) (05/07/90)
> I have xdm running on the Symmetry with the authorize resource set to > true and a protocol of MIT-MAGIC-COOKIE-1. For my display server, I have > the R4 sample server running on a Sun which was invoked with the > command Xsun -query <host machine>. > > Xdm and the display server start up and talk to each other fine and xdm > creates an .Xauthority file in the user's account and a file to pass the > key to the server. However I see the following problems: > > 1. On every session, the same key is generated each time (all f's). XDM attempts to generate cryptographically secure random numbers to be used as authorization data -- this way the current session user cannot predict the authorization data which will be used by the next session. To do this, it uses the DES password encryption routines from your C library as I could not include DES code in the release because of export restrictions. Unfortunately, almost every system has a different arrangement of these routines; perhaps DYNIX could use some configuration assistance. Look in the file mit/clients/xdm/cryptokey.c for the convoluted set of #ifdef/#defines which attempt to do sensible things. I suspect it is trying to use setkey/encrypt (the low level DES primitives) instead of crypt (the password algorithm). If setkey/encrypt don't work correctly, you'll end up with a password of either all 0's or all 1's. > 2. The server always refuses access to the clients started by the > user's .xsession. The clients that try to start up are 2 xterms, > an xclock and an xbiff (all versions supplied with the R4 tape). > The error message they get is: (The error message was missing in original message, I assume it was "Client is not authorized to connect to Server") This one I don't understand. I use my VS2000 as an X terminal every day, connected to my DS3100. MIT-MAGIC-COOKIE-1 works correctly in this environment. Make sure you use the R4 X library to link clients with; the authorization stuff happens behind the scenes inside XOpenDisplay. You should make sure the clients you are starting have access to the .Xauthority file. If they are running machine with a different home directory for the user, you'll need to rcp the file before attempting to run the clients. Note that X clients cannot be started from the .Xstartup/.Xreset scripts; they do not have the XAUTHORITY environment variable set while they are running. (This is a bug in the R4 version of xdm). > 1. Cookie files > > Also, I have some questions about the .Xauthority file and the > file passed to the server with the key. Do both of these files > consist of Xauth records (defined in Xauth.h)? I can look at both > of these files with xauth but I notice xauth only shows display_name > protocol and key. It doesn't show the rest of the fields in Xauth: > family, address, number and their respective lengths. Are these fields > just considered to be not of interest or does xauth show display_name > in lieu of these fields. I can understand what family, address and number > mean in the user's .Xauthority file but what are these fields supposed to > be set to in the file passed to the server? I notice a define in > Xauth.h called FamilyWildcard. Should the family for this file > be FamilyWildcard with the address and number fields just ignored? Yes, both of these files consist of Xauth records. The server, however, doesn't need address or transport information, so the address and number fields are empty while the family field is set to FamilyWild. This means that the server should match any incoming connection when using this authorization scheme. In the .Xauthority file, all of the fields are used when selecting the authorization name/data to use in the connection. xauth implicitly displays this information when it displays the contents of the file. The family is IP when the name:number format is used (just like XOpenDisplay), while name/unix:0 is used for local connections. The various length fields are used to print the correct amount of information for each field. Here's an example: mfb.lcs.mit.edu:0 MIT-MAGIC-COOKIE-1 3262327a76385744444e684546754a66 xenon.lcs.mit.edu:0 MIT-MAGIC-COOKIE-1 643049744b554c314943654234635655 xenon.lcs.mit.edu/unix:0 MIT-MAGIC-COOKIE-1 643049744b554c314943654234635655 So, this has an authorization entry for the IP family address mfb.lcs.mit.edu on display 0, authorization name MIT-MAGIC-COOKIE-1 with the given data. It also has two entries for xenon.lcs.mit.edu, one for IP connections and one for local connections (using unix domain sockets). Notice that both authorization entries for xenon.lcs.mit.edu have the same authorization data; this is because xdm uses the same data for each potential address. If xenon.lcs.mit.edu had more than one network interface, it would have multiple IP entries, one per address (which would be indistinguishable here as xauth converts the IP addresses to hostnames). > 2. Clients > > What do writers of client programs need to know about security > to make their clients play well with authorization schemes? > I notice the README in the Xau directory seems to be saying > the the client writer doesn't need to do anything - that a > call to XOpenDisplay will take care of everything. Is this true? In general, yes, the R4 version of XOpenDisplay will search the .Xauthority file for an entry which matches the display family/address/number. There is a hook in the R4 Xlib which allows the client to preset the authorization information to be used in the XOpenDisplay call (XSetAuthorization). Xdm uses this to connect to the display the first time, even though it could avoid this by simply setting the XAUTHORITY environment variable correctly. Keith Packard MIT X Consortium