This page is a part of XSecurePro64 online Help Manual.
|6. Configuring XSecurePro64||< previous | content | next >|
This item allows you to make a choice of the XServer startup mode. Select a desired window mode by clicking on a mode name. (For more information, see related sections in Chapter Using XServer.)
In this mode, MS Windows works as a local window manager for your X clients. When an X client starts, it appears in a window like any other displayed by MS Windows. Each client you start creates its own window on your display. The client window's controls (i.e. its borders, the Control Menu box, move window functions, etc.) are all handled by MS Windows on your PC.
This mode presents all X clients in a single X-session window. Within the window, the window management and all other functions are typically controlled by an X Window System manager you start on a host. The X-session window itself can be sized and moved like any other MS Windows window.
This mode presents all X clients in a single root window taking up full the screen outside the MS Windows graphical environment. The window management and all other functions are typically controlled by an X Window System window manager you start on a host.
This mode is the above Multiple mode, but the local MS Windows window manager does not control windows of X clients and a user has to run any suitable remote window manager. The mode is very convenient when users use CDE-like interface where a remote window manager provides its own tool/task bar.
X Display Manager Control Protocol (XDMCP) is a popular method of starting remote login sessions. Once XServer configured to use XDMCP has initiated X-session for the first time, it contacts an 'xdm' process running on a host system.
XDMCP settings are used to control the XDMCP startup method. The Use XDMCP check box lets you specify the XDMCP settings.
Change XDMCP settings only after consulting with your system administrator.
You can check one of the following XDMCP modes:
In this mode, a particular host used to establish the X connection must be specified in the Connect Host field.
This mode does not allow you to specify a host in the Connect Host field. Instead,
XServer will broadcast a request to start the X connection to every host named in the
Broadcast List File.
To use this mode, you must create a Broadcast List File.
If you select the Broadcast mode, then the Select XDMCP Host window will appear after loading XServer. In this window, you will see the XDMCP hosts running on your network, and you can select one of them to start the X-session.
The query will be sent to the host specified in the Connect Host field. Then this host will either start up or broadcast a request for one or more other hosts to start the X connection.
This field is used to specify a network node name or IP address for the host you want to connect to in the Query or Indirect startup mode.
When you click on the scroll arrow beside the Connect Host box, a drop-down box will display host definitions listed in your hosts file. To select a host, just click on an appropriate definition.
If the hosts file does not contain the host definition you need, you can enter the host's IP address in the field (in the standard dotted IP address notation).
In the Broadcast startup mode, specify a file that contains a list of hosts that your PC will transmit a 'broadcast' message to.
The file consists of text lines each of the following format:
Names must be specified as official host names or aliases in your hosts file. Note that the syntax allows you to use the hosts file as the Broadcast List File.
Note: if you leave this field empty or enter either 0.0.0.0 or 255.255.255.255 (these special destination addresses specify a broadcast), then this will provide the XDMCP broadcast mode (when your PC will transmit a 'broadcast' message to every host on your local network to query all XDMCP daemons).
If checked, this check box enables closing all X clients if the remote XDM daemon terminates the XDMCP session with XServer.
Check this check box if you are going to use the CDE XDMCP mode, i.e. with CDE installed on the remote XDMCP host (for the XServer's Multiple window mode only).
This option provides the "old-style" way of using the XDMCP broadcast mode.
This check box allows you to enable the XDM-AUTHENTICATION-1 and XDM-AUTHORIZATION-1 schemes. If your host is using XDM authentication or XDM authorization scheme, set up the values in the Display ID, Display Class, and Key fields and report them to your system administrator.
If you disable XDM authentication/authorization, then XServer will use the default client authorization scheme, MIT-MAGIC-COOKIE-1.
According to the XSECURITY manual page of X Window System, X provides mechanism for implementing many access control systems. The sample implementation includes some mechanisms with MIT-MAGIC-COOKIE-1 (using shared plain-text "cookies") and XDM-AUTHORIZATION-1 (using secure DES-based private-keys) being two of them.
When using MIT-MAGIC-COOKIE-1, the client sends a 128-bit "cookie" along with the connection setup information. If the cookie presented by the client matches one that the X server has, the connection is allowed access. The cookie is chosen so that it is hard to guess; xdm generates such cookies automatically when this form of access control is used. The user's copy of the cookie is usually stored in the .Xauthority file in the home directory, although the environment variable XAUTHORITY can be used to specify an alternate location. Xdm automatically passes a cookie to the server for each new login session, and stores the cookie in the user file at login.
The cookie is transmitted on the network without encryption, so there is nothing to prevent a network snooper from obtaining the data and using it to gain access to the X server. This system is useful in an environment where many users are running applications on the same machine and want to avoid interference from each other, with the caveat that this control is only as good as the access control to the physical network. In environments where network-level snooping is difficult, this system can work reasonably well.
This system uses 128 bits of data shared between the user and the X server. Any collection of bits can be used. Xdm generates these keys using a cryptographically secure pseudo random number generator, and so the key to the next session cannot be computed from the current session key.
Sites in the United States can use a DES-based access control mechanism called XDM-AUTHORIZATION-1. It is similar in usage to MIT-MAGIC-COOKIE-1 in that a key is stored in the .Xauthority file and is shared with the X server. However, this key consists of two parts - a 56-bit DES encryption key and 64 bits of random data used as the authenticator.
When connecting to the X server, the application generates 192 bits of data by combining the current time in seconds (since 00:00 1/1/1970 GMT) along with 48 bits of "identifier". For TCP/IP connections, the identifier is the address plus port number; for local connections it is the process ID and 32 bits to form a unique id (in case multiple connections to the same server are made from a single process). This 192-bit packet is then encrypted using the DES key and sent to the X server, which is able to verify if the requestor is authorized to connect by decrypting with the same DES key and validating the authenticator and additional data. This system is useful in many environments where host-based access control is inappropriate and where network security cannot be ensured.
This system uses two pieces of information. First, 64 bits of random data, second a 56-bit DES encryption key (again, random data) stored in 8 bytes, the last byte of which is ignored. Xdm generates these keys using the same random number generator as is used for MIT-MAGIC-COOKIE-1.
This button sets up the default values for check boxes and edit fields in the Use XDMCP box.
If XDM authentication or XDM authorization has been enabled on the XDM host, your system administrator will need to know the value displayed in this field. This field should normally never be changed. The Display ID value consists of these two parts separated by hyphen: the Display Class value and the arbitrary numerical value.
In very rare cases, your system administrator may determine that your Display ID
is a duplicate and will ask you to generate a new one. To do this, use arrows on the right
side of the Display ID field. The up arrow increases the numerical value of the
Display ID, and the down arrow decreases it.
Do not do this without consulting with your administrator.
This field can be used to group classes of XDM nodes. The field should only be modified at the request of your system administrator. Otherwise it should be left unchanged.
This field defines the key used in XDM authentication. If your host is using XDM authentication, your system manager will need to know the contents of your XDMCP Key and Display ID fields. This field should only be modified at the request of your system administrator. Otherwise it should be left unchanged.
|6. Configuring XSecurePro64||< previous | content | next >|
|Copyright © 1999 - 2009 LabtamTM Inc.|