This page describes Host Access Control security, also known as XDM Magic
Cookie. The @workStation's local xhost client is also discussed.
Host
Access Control Security
The host-based security of the hosts.equiv and .rhosts file can also be
extended to a user-based security procedure, called MIT-MAGIC-COOKIE-1, which
is supported by the HDS @workStation. This security procedure extends the
security of the user's account and password to all clients on the system. The
procedure is simple and almost invisible to the user.
Note that for some systems (such as OpenWindows), this security is On
by default.
Host Access Control from Setup Mode
A new resource has been added to permit the @workStation to use Access
Control security when you are not using Xdmcp. It uses the first remote client
to connect as its Access Control.
The resource is in the cfg.syntax file. The default is disabled.
HDSsetup.default.AccessControl: [ DISABLED | ENABLED ]
Using Magic Cookie Security
When a session is started with Xdm, a special code (the Magic Cookie) is
written to the .Xauthority file in the user's home directory. This .Xauthority
file has restricted permissions (-rw-------) so only the original user can read
it. Before any new clients can start, they must read this file to obtain the
Magic Cookie to be able to start their process. If they aren't the original
user, they can't read the file and access is denied. The key to Magic Cookie
security is the integrity of the user's account and password. If anyone can
read the user's .Xauthority file, then this security mechanism is useless.
Starting Magic Cookie Security in Xdm
This security is started in the Xdm configuration file, xdm-config, with
two resources: DisplayManager._0.authorize: true
DisplayManager*authorize:
true
The first resource turns on authorization for the local display
and the second turns it on for for all other displays. You can disable
authorization by setting these to "false" and restarting Xdm. This is
the proper way to disable authorization for your Xdm process.
There is also a way to disable it by allowing authorization for all
users. This is discussed in the sections below.
More details on Xdm
operation and setup are found on the Automatic Starting with
Xdm page.
Magic Cookie Security on the @workStation
The HDS @workStation controls its response to Magic Cookie requests by the "Host
Access Control" field in the XDMCP menu of Setup Mode. This permits you to
enable or disable this security feature on the @workStation. Note that this is
turned ON in its default configuration.
Problems with Magic Cookie Authentication
Sometimes a problem arises with Magic Cookie authentication. Its symptom is
that the user can log on with Xdm and use processes on the Xdm host but cannot
start processes on other hosts. There are two difficulties observed.
1.
Authentication is On by default with R5; users may not be aware of the
authentication process. Typically, the problem doesn't show itself until the
user tries to log onto a host other than the Xdm host and cannot do so.
A
faulty "Magic Cookie" is created by some Xdm clients.
In both of these cases, there are ways to disable or to extend the
authentication so your system can be accessible to all users. These are
important considerations and need careful security control.
Extending User Authentication
Most systems have an MIT resource for the login client that permits
disabling the access control. This resource is available in both R4 and R5
versions. In your /usr/ lib/X11/xdm/Xresources file, set the resource: xlogin*allowAccess:
true
This allows access to the session for all users, thus
effectively disabling Magic Cookie authentication.
You can also set this resource with the key sequence Ctrl-+ (some
systems have not implemented this key translation to set the allowAccess
resource from the keyboard). You can use the Ctrl-+ key sequence at any time,
including when the Xdm login window is present. When you press the Ctrl-+
sequence, you will notice the login banner change to "This is an unsecure
session", which means that the authentication feature is disabled. Note
that Ctrl-+ toggles the allowAccess resource, so if it was initially Off, this
can turn it On. In this way, the user can select the authentication he wants
for the system.
Extending Magic Cookie Authentication
We have observed that some versions of Xdm (a host-based client) do
not work correctly and create an invalid Magic-Cookie. This means that the user
can only gain access to the original Xdm host. Other hosts will have access
denied and will report authentication and permission errors. This condition
arises because the host's Xdm process generates an incorrect Cookie (typically
all F's).
If you have this problem, you can explicitly extend authentication to
one or more hosts. This is the intended method of operation, so user security
is controlled by the Magic Cookie. In a practical sense, extending
authentication to all hosts is the same as disabling the authentication.
@workStation xhost Client
This page describes
extending Magic Cookie authentication using the @workStation's xhost client.
Return to Section Heading Page
Return to the Home
Page
If you need more information than is available here, you can reach HDS via
email at info@hds.com, or call us at
1.800.HDS.1551 in the USA, or at +610.277.8300 from outside the US. For
questions or problems regarding the HDS WWW page, contact
webmaster@hds.com.
© 1996 by HDS Network Systems Inc.