HP OpenVMS Systems Documentation

The MIT-MAGIC-COOKIE-1 protocol was designed to provide a more secure alternative to the host-based security mechanism (xhost) available in previous releases of the X Window System. The first protocol to use a token-based approach, it provided the initial, standard means for restricting access to the X server on a user level.

Magic Cookie authorizes connections to an X server based on entries in the X authority file. Each entry for Magic Cookie access control specifies:

• the name of the X display ([transport/][host][:]:server[.screen])
• the protocol name (MIT-MAGIC-COOKIE-1)
• a random, 128-bit numeric code known as a magic cookie

Magic Cookie access control can be implemented one of two ways depending on your DECwindows Motif system environment:

• For access control outside a DECwindows Motif session, manually create the X authority file and reference that file using the DECW$SERVER_XAUTHORITY server parameter, as described in Section 2.6.3.1.5.
• For access control inside a DECwindows Motif session, use the Security Options dialog box to enable access control, as described in Section 2.6.3.2.2.

When Magic Cookie is used to authorize connections during a DECwindows Motif session, a cookie is generated each time a user successfully logs into their local DECwindows Motif desktop. The magic cookie authorizing the local connection, along with the device, transport, and protocol name is passed to the X server and stored in the current X authority file (SYS$LOGIN:DECW$XAUTHORITY.DECW$XAUTH).

Each time a client application attempts to connect to the X server during the session, the application must present a valid cookie to the X server along with the connection request. If the cookie matches the one maintained by the X server, the connection is authorized, access is granted to the X server, and the display is opened.

If the client does not present a valid cookie, the following message is displayed, and the connection is denied:

Xlib: connection to "0:0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
X Toolkit Error:  Can't Open display

When the user logs out of the DECwindows Motif session, the server is reset, and the cookie is discarded.

The basic authorization process remains the same when Magic Cookie is used to authorize X server connections outside of a DECwindows Motif session. However, the file creation process is not. Both the X authority file and the magic cookie must be manually generated.

Due to the use of a randomly-generated token, Magic Cookie provides a more secure form of access control than the user-based scheme. However, the cookies are sent across the network unencrypted, leaving them prone to interception. As a result, this form of access control is recommended for authorizing connections in a local area network (LAN) or limited DECnet environment.

2.6.2.2 Kerberos (MIT-KERBEROS-5)

Kerberos authorizes connections to an X server based on a combination of the following:

• the protocol name (MIT-KERBEROS-5) in the X authority file
• a list of valid Kerberos principals and their associated passwords
• presentation of valid credentials

Kerberos credentials, or tickets, are a set of electronic information that can be used to verify the identity of a principal. These principals are stored in an Authorized Principals list kept on the server system. With Kerberos, client applications run by a valid principal send requests for a ticket from the Kerberos Key Distribution Center (KDC) each time they attempt to connect to the Kerberos-protected X server.

Kerberos access control can be implemented one of two ways depending on your DECwindows Motif system environment:

• For access control outside a DECwindows Motif session, manually create the X authority file and reference that file using the DECW$SERVER_XAUTHORITY server parameter, as described in Section 2.6.3.1.6.
• For access control inside a DECwindows Motif session, use the Security Options dialog box to enable access control and add users to the Authorized Principals list, as described in Section 2.6.3.2.3.

Once Kerberos access control is enabled on the server, a new ticket is requested from the KDC automatically each time a user logs into their local desktop. The KDC creates a ticket-granting ticket (TGT) associated with the user's principal name, encrypts it using the password as the key, and returns the encrypted TGT.

If the TGT is decrypted successfully, the user is authenticated and the TGT is cached. The TGT permits the authenticated principal to obtain additional tickets. These additional tickets grant access to specific services, in this case, access to the X server from other client applications. The requesting and granting of these additional tickets happens transparently.

With DECwindows Motif, user-to-user authentication is employed. In this model, both the client and server use a Kerberos client at each end of the connection to verify the identify of the user (principal). Once the principal is authenticated at both ends of the connection, access is granted to the X server.

By default, each TGT expires at a specified time. If a TGT has expired or been compromised, you can choose to revoke the current TGT and generate a new TGT by forcing a Kerberos login.

The basic authorization process remains the same when Kerberos is used to authorize X server connections outside of a DECwindows Motif session. However, the credential initialization is not. The user who is running the client application must force initialization using the Kerberos Inititialization utility (kinit) or by forcing a login through OpenVMS.

Kerberos is the most secure form of access control since it encrypts the initial authentication information between the requesting client and the server system. Therefore, it is the recommended method for authorizing remote client connections over unsecure networks, such as the Internet.

When configuring access control for the X display server, you can choose to apply a traditional user-based scheme, a token-based scheme (such as Magic Cookie or Kerberos), or a combination of schemes depending upon your network environment. For example, you may choose to use Kerberos to authorize all remote server connections over TCP/IP and Magic Cookie to authorize LAN network connections.

When used in combination, the most restrictive access control scheme presented by the client always takes precedence. For example, if the server has all three schemes enabled, and the requesting client is using Magic Cookie, the server will attempt to authorize the connection via Magic Cookie. Note with Magic Cookie access control, user-based access is available by default. If the client attempts and fails to connect to the server using a token-based scheme and is also a member of the Authorized Users list, then access will be granted.

Before enabling access control, take the following actions:

Enabling access control outside of a DECwindows Motif desktop session allows authorized OpenVMS users to run X Window System client applications on systems without a login process. This type of access control is used typically for systems that function as a standalone X server, versus an interactive DECwindows Motif workstation.

Use the server customization parameters and either the access allowed or X authority file to set access control, as described in the following sections.

2.6.3.1.1 The Access Allowed File

By default, access to the DECwindows X11 Display Server prior to login is limited to the local SYSTEM account via the DECnet or local transport. The access allowed file is an ASCII text file that grants additional OpenVMS users access to the X server automatically at server startup.

The access allowed settings remain in effect until a user logs into a DECwindows Motif desktop. Once a user logs into a desktop and begins a DECwindows Motif session, any security options defined with the Session Manager for that user are applied. If a token-based access control scheme has been enabled, additional information may need to be provided by a client application or user in order to gain access to the X server. See Section 2.6 for more information on token-based schemes currently supported by DECwindows Motif.

Once the user ends the session, the server is reinitialized, and the access allowed settings are restored.

Not to be confused with trusted network connections, as described in Section 1.2.2.7, trusted users are those who are authorized to change security settings. The access trusted file is an ASCII text file that identifies which OpenVMS users can change the access control settings for a particular DECwindows X11 Display Server.

By default, the local SYSTEM account is granted trust privileges (via the local or DECnet transport). However, when using token-based authentication, trust privileges are not assigned by default. You must manually assign these privileges using the access trusted file.

Entries in this file are automatically added to the access allowed list, unless a token-based authentication scheme is in place. In that case, trusted users must be granted access to the X server either through a manual entry to the access allowed list or via an entry in the appropriate X authority file. Similar to the settings in an access allowed file, access trusted settings remain in effect until a user logs into a DECwindows Motif desktop.

2.6.3.1.3 Format of File Entries

Depending on the access control method in place, the format of file entries can differ.

For User-Based or Magic Cookie Access Control

Each entry in an access allowed or access trusted file follows the transport-host-username format currently used by the DECwindows Motif security options, as described in Using DECwindows Motif for OpenVMS.

For example, the following entries in an access allowed file grant user JONES local access to the server as well as network access from node ZEPHYR via the DECnet transport:

DECNET ZEPHYR JONES
LOCAL 0 JONES
   .
   .
   .

Note that when using TCP/IP as the network transport, access and trust privileges can only be assigned to a host versus to specific users. TCP/IP does not provide the user specification as part of the data provided on a remote connection.

As a result, file entries for hosts using TCP/IP must contain an asterisk (*) for the user specification. This grants all users on a particular host system access or trust privileges when they connect to the X server using TCP/IP. For example, the following entry in an access allowed file grants access to all users on node ZEPHYR via the TCP/IP transport:

TCPIP ZEPHYR *
   .
   .
   .

For Kerberos Access Control

Under Kerberos access control, entries are only allowed in the access allowed file. Each entry for a Kerberos principal in an access allowed file follows the protocol-principal@realm-accessrights format, where accessrights can be NONE, ALL, or *.

For example, the following entry in an access allowed file grants principal JONES access to the server via the TCP/IP transport:

KERBEROS jones@ORG.COMPANY.COM ALL
   .
   .
   .

To apply user-based access control outside of a DECwindows Motif session, establish an access allowed and access trusted file, as follows:

1. Edit the file SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM.
2. Define the value of the DECW$SERVER_ACCESS_ALLOWED or DECW$SERVER_ACCESS_TRUSTED parameter so that it refers to the location where each file is stored, such as:

   $ DECW$SERVER_ACCESS_ALLOWED == "SYS$MANAGER:DECW$SERVER1_ACCESS_ALLOWED.DAT" $ DECW$SERVER_ACCESS_TRUSTED == "SYS$MANAGER:DECW$SERVER1_ACCESS_TRUSTED.DAT"

3. Save the file.
4. Create and edit the access allowed or access trusted file adding the appropriate user entries.

   Note Trust privileges do not automatically grant access to the X server when using token-based authentication. If you are creating an access trusted list on a system that has either Magic Cookie or Kerberos enabled, each user on that list must also have a valid entry in the related access allowed file or X authority file in order to access the X server.

5. Save the file and restart the server. The new access or trust privileges are applied automatically at startup.

To apply Magic Cookie access control outside of a DECwindows Motif session, do the following:

1. Log into the SYSTEM account or another privileged account.
2. Edit the DECW$PRIVATE_SERVER_SETUP.COM file and define the value of the DECW$SERVER_XAUTHORITY parameter so that it refers to the location where the X authority file will be stored, such as:

   $ DECW$SERVER_XAUTHORITY == "SYS$MANAGER:SERVER_ZEPHYR.DECW$XAUTH"

3. Exit and save the file.
4. Using xauth, manually create the X authority file for the server and add the appropriate entries. For example, the following command creates the new X authority file SERVER_ZEPHYR.DECW$XAUTH, adds the entry for the local transport, specifies the Magic Cookie protocol, and assigns a cookie value of 12345abcdef56789:

   $ XAUTH -f SYS$SYSROOT:[SYSMGR]SERVER_ZEPHYR.DECW$XAUTH ADD - _$ :0 MIT-MAGIC-COOKIE-1 12345abcdef56789

   
   The authorization key in this file is loaded into the X server at start up and can be used to authorize all client connections, regardless of display name.
5. Restart the server.
6. Propagate the key to all client systems using xauth, as described in Section 1.2.2.6.

2.6.3.1.6 Kerberos Access Control

In order to enable Kerberos, you or your system administrator must have first performed the following on the server system:

1. Installed and configured the TCP/IP for OpenVMS Alpha software with a domain name server.
2. Installed and configured the Kerberos Client for OpenVMS software, as described in the Kerberos Client for OpenVMS Installation Guide and Release Notes.
3. Obtained the following information:
   • Location of the KDC
   • The appropriate node, domain, and realm information for adding principals
   • Your principal name and password
4. Enable the SECURITY extension and TCP/IP transport by defining the DECW$SERVER_EXTENSIONS and DECW$SERVER_TRANSPORTS parameters in SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP and restarting the server.

To apply Kerberos access control outside of a DECwindows Motif session, do the following:

1. Invoke the Kerberos Administration utility, as follows:

   $ KERBEROS/INTERFACE=DECWINDOWS/ADMIN

2. Create the following principal, keytab file, and keytab file entry. Refer to your Kerberos Client for OpenVMS documentation for information on how to use the Kerberos Administration Utility.
   • Create the principal x0/host@REALM, for example:

     x0/system@ORG.COMPANY.COM

   • Create the keytab file SYS$SYSROOT:[SYSMGR]DECW$X0.KEYTAB.
   • Create an entry in that keytab file for principal x0.
3. Edit the DECW$PRIVATE_SERVER_SETUP.COM file and define the values of the following parameters so that they refer to the location where the X authority file, access allowed, and access trusted files will be stored, such as:

   $ DECW$SERVER_XAUTHORITY == "SYS$MANAGER:SERVER_ZEPHYR.DECW$XAUTH" $ DECW$SERVER_ACCESS_ALLOWED == "SYS$MANAGER:DECW$SERVER_ZEPHYR_ACCESS_ALLOWED.DAT" $ DECW$SERVER_ACCESS_TRUSTED == "SYS$MANAGER:DECW$SERVER_ZEPHYR_ACCESS_TRUSTED.DAT"

4. Exit and save the file.
5. Using xauth, manually create the X authority file for the server, and add the appropriate entries. For example, the following command creates the new X authority file SERVER_ZEPHYR.DECW$XAUTH, adds the entry for the local transport, specifies the Kerberos protocol, and assigns a cookie value, which is the hexadecimal representation of the keytab file specification:

   $ XAUTH -f SYS$SYSROOT:[SYSMGR]SERVER_ZEPHYR.DECW$XAUTH ADD - _$ :0 MIT-KERBEROS-5 - _$ 43533a78302c53595324535953524f4f543a5b5359534d47525d44454 - _$ 3572458302e4b4559544142

6. Exit and save the file.
7. Manually create an access trusted file in the location specified by the DECW$SERVER_ACCESS_TRUSTED parameter, and add an entry for the SYSTEM account, as follows:

   * SYSTEM 0

8. Manually create an access allowed file in the location specified by the DECW$SERVER_ACCESS_ALLOWED parameter, and place an entry in the file for each Kerberos principal you want to grant access to the server.
9. Restart the server.

Use the Security Options dialog box to set the access control scheme in effect inside a DECwindows Motif session. The options in the dialog box enable you to set the access control scheme used by the local X display server, authorize other users access to the X server, and specify the scheme local client applications use when connecting to an X server.

Accessed from the Session Manager (Traditional Desktop) or Style Manager (New Desktop), the settings in Security Options dialog box are identical. Note, however, each desktop stores the settings differently:

• Settings in the Traditional Desktop are stored in the DECW$SMB_SECURITY.DAT file as soon as the changes are applied.
• Settings in the New Desktop are saved whenever a session is saved (such as, when saving a new home session or when saving the current session). Note that on the New Desktop, if you chose to restore the home session on next login, any changes will be lost unless you save them by updating the home session.

To enable user-based access control and grant one or more authorized users access to your workstation display:

1. Do one of the following, depending on the desktop:
   • From the Traditional Desktop, choose Security... from Session Manager's Options menu.
   • From the New Desktop, click the Style Manager Security control.
   
   The Security Options dialog box is displayed.
2. Under Server Access Control, click Users... to display the Configure Users dialog box.
3. Type the node, the username, and the method of transport for the users you want to authorize.
4. Click on the Add button. The users are added to the Authorized Users list.
5. Click on OK to save and apply the changes and close the Configure Users dialog box.

To disable user-based access control, you must remove all users from the Authorized Users list.

To remove a user name, first click on the names you want to remove. Then click on the Remove button. Finally, click on OK or Apply. The users will no longer have authorized access to your workstation.