Security

PAM

GDM uses PAM for login authentication, though if your machine does not support PAM you can build GDM to work with the password database and the crypt library function.

PAM stands for Pluggable Authentication Module, and is used by most programs that request authentication on your computer. It allows the administrator to configure different authentication behavior for different programs.

Some GDM features (like turning on automatic login) may require that you update your PAM configuration. PAM configuration has different, but similar, interfaces on different operating systems, so check your pam.d or pam.conf man page for details. Be sure that you read the PAM documentation (e.g. pam.d/pam.conf man page) and are comfortable with the security implications of any changes you intend to make to your configuration.

If there is no entry for GDM in your system's PAM configuration file, then features like automatic login may not work. Not having an entry will cause GDM to use default behavior, conservative settings are recommended and probably shipped with your distribution.

If you wish to make GDM work with other types of authentication mechanisms (such as a SmartCard), then you should implement this by using a PAM service module for the desired authentication type rather than by trying to modify the GDM code directly. Refer to the PAM documentation on your system. This issue has been discussed on the

mail list, so you can refer to the list archives for more information.

For example, an effective way to implement such an exotic authentication mechanism would be to have a daemon running on the server listening to the authentication device (e.g. USB key, fingerprint reader, etc.). When the device announces that it has received input, then the daemon can set the PamStack configuration value using per-display configuration, and restart the greeter with the PAM stack that works with this device. This avoids needing to hack the display manager code directly to support the feature.

utmp/wtmp

GDM generates utmp and wtmp User Accounting Database entries upon session login and logout. The utmp database contains user access and accounting information that is accessed by commands such as finger, last, login, and who. The wtmp database contains the history of user access and accounting information for the utmp database.

GDM 2.18 and earlier would run the X server sessreg program from the default GDM PreSession and PostSession scripts. Starting with GDM 2.20, GDM interacts with the UTMP and WTMP databases directly and supports the following configuration options.

When doing utmp processing, GDM supports configurability on how the ut_line value is set. Programs that access the database assume that this value is an actual device, so GDM will set the device as follows. If the display is attached and has an associated Virtual Terminal (VT) device, then this device will be used. Otherwise, if an attached display in the [servers] specifies a device name, then this value will be used. Otherwise attached displays will default to the UtmpLineAttached value in the GDM configuration. Remote displays will default to the UtmpLineRemote value in the GDM configuration. Device values must begin with "/dev/".

GDM also supports the UtmpPseudoDevice configuration option. If this configuration setting is true, then GDM will ensure that the specified device exists and will create a pseudo device if the device does not exist. A pseudo device is a symlink to /dev/null. If UtmpPseudoDevice is true, and the device does already exist, GDM checks to see if the device is a symlink to /dev/null. If so, then GDM will update the access time of the symlink. This ensures that programs that check the access time of the device will get a reasonable value for the last time the device was accessed. If the UtmpPseudoDevice configuration option is false, then GDM will only set the ut_line value as specified regardless of whether the device exists or not.

The GDM User

For security reasons a dedicated user and group id are required for proper operation! The need to be able to write Xauth files is why user "nobody" is not appropriate for gdm.

The GDM daemon normally runs as root, as does the slave. However GDM should also have a dedicated user id and a group id which it uses for its graphical interfaces such as gdmgreeter and gdmlogin. These are configured via the User and Group configuration options in the GDM configuration files. The user and group should be created before running "make install". By default GDM assumes the user and the group are called "gdm".

This userid is used to run the GDM GUI programs required for login. All functionality that requires root authority is done by the GDM daemon process. This design ensures that if the GUI programs are somehow exploited, only the dedicated user privileges are available.

It should however be noted that the GDM user and group have some privileges that make them somewhat dangerous. For one, they have access to the X server authorization directory. It must be able to read and write Xauth keys to <var>/lib/gdm. This directory should have root:gdm ownership and 1770 permissions. Running "make install" will set this directory to these values. The GDM daemon process will reset this directory to proper ownership/permissions if it is somehow not set properly.

The danger is that someone who gains the GDM user/group privileges can then connect to any session. So you should not, under any circumstances, make this some user/group which may be easy to get access to, such as the user nobody. Users who gain access to the "gdm" user could also modify the Xauth keys causing Denial-Of-Service attacks. Also if a person gains the ability to run programs as the user "gdm", it would be possible to snoop on running GDM processes, including usernames and passwords as they are being typed in.

Distributions and system administrators using GDM are expected to setup the dedicated user properly. It is recommended that this userid be configured to disallow login and to not have a default shell. Distributions and system administrators should set up the filesystem to ensure that the GDM user does not have read or write access to sensitive files.

X Server Authentication Scheme

The X server authorization directory (the ServAuthDir) is used for a host of random internal data in addition to the X server authorization files, and the naming is really a relic of history. GDM daemon enforces this directory to be owned by root.gdm with the permissions of 1770. This way, only root and the GDM group have write access to this directory, but the GDM group cannot remove the root owned files from this directory, such as the X server authorization files.

GDM by default doesn't trust the X server authorization directory and treats it in the same way as the temporary directory with respect to creating files. This way someone breaking the GDM user cannot mount attacks by creating links in this directory. Similarly the X server log directory is treated safely, but that directory should really be owned and writable only by root.

GDM only supports the MIT-MAGIC-COOKIE-1 X server authentication scheme. Normally little is gained from the other schemes, and no effort has been made to implement them so far. Be especially careful about using XDMCP because the X server authentication cookie goes over the wire as clear text. If snooping is possible, then an attacker could simply snoop your authentication password as you log in, regardless of the authentication scheme being used. If snooping is possible and undesirable, then you should use ssh for tunneling an X connection rather then using XDMCP. You could think of XDMCP as a sort of graphical telnet, having the same security issues.

On the upside, GDM's random number generation is very conservative and GDM goes to extraordinary measures to truly get a 128 bit random number, using hardware random number generators (if available), plus the current time (in microsecond precision), a 20 byte array of pseudorandom numbers, process pid's, and other random information (possibly using /dev/audio or /dev/mem if hardware random generators are not available) to create a large buffer and then run MD5 digest on this. Obviously, all this work is wasted if you send this cookie over an open network or store it on an NFS directory (see UserAuthDir configuration key). So be careful about where you use remote X display.

Firewall Security

Even though GDM tries to outsmart potential attackers trying to take advantage of XDMCP, it is still advised that you block the XDMCP port (normally UDP port 177) on your firewall unless you really need it. GDM guards against DoS (Denial of Service) attacks, but the X protocol is still inherently insecure and should only be used in controlled environments. Also each remote connection takes up lots of resources, so it is much easier to DoS via XDMCP then a webserver.

It is also wise to block all of the X Server ports. These are TCP ports 6000 + the display number of course) on your firewall. Note that GDM will use display numbers 20 and higher for flexible on-demand servers.

X is not a very safe protocol for leaving on the net, and XDMCP is even less safe.

GDM Security With NFS

Note that NFS traffic really goes "over the wire" and thus can be snooped. When accessing the user's X authorization file (~/.Xauthority), GDM will try to open the file for reading as root. If it fails, GDM will conclude that it is on an NFS mount and it will automatically use UserAuthFBDir, which by default is set to /tmp. This behavior can be changed by setting the NeverPlaceCookiesOnNFS in the [security] section to false.

XDMCP Security

Even though your display is protected by cookies, XEvents and thus keystrokes typed when entering passwords will still go over the wire in clear text. It is trivial to capture these.

XDMCP is primarily useful for running thin clients such as in terminal labs. Those thin clients will only ever need the network to access the server, and so it seems like the best security policy to have those thin clients on a separate network that cannot be accessed by the outside world, and can only connect to the server. The only point from which you need to access outside is the server.

The above sections "X Server Authentication Scheme" and "Firewall Security" also contain important information about using XDMCP securely. The next section also discusses how to set up XDMCP access control.

To workaround the inherent insecurity of XDMCP, gdm proposes a default built-in session that uses SSH to encrypt the remote connection. See the section "Securing remote connection through SSH" above.

XDMCP Access Control

XDMCP access control is done using TCP wrappers. It is possible to compile GDM without TCP wrappers however, so you should test your configuration and verify that they work.

You should use the daemon name gdm in the <etc>/hosts.allow and <etc>/hosts.deny files. For example to deny computers from .evil.domain from logging in, then add

gdm: .evil.domain

to <etc>/hosts.deny. You may also need to add

gdm: .your.domain

to your <etc>/hosts.allow if you normally disallow all services from all hosts. See the hosts.allow(5) man page for details.

RBAC (Role Based Access Control)

If GDM is compiled with RBAC support, then the RBACSystemCommandKeys configuration option can be used to specify the RBAC key to be used to determine if the user has authority to use commands. This is supported for the Shutdown, Reboot, Suspend, and Custom Commands that appear in the GDM greeter and via the gdmflexiserver QUERY_LOGOUT_ACTION, SET_LOGOUT_ACTION, and SET_SAFE_LOGOUT_ACTION commands. The greeter will only display the option if the gdm user (specified by the User configuration option) has permission via RBAC. Users will only be able to use the gdmflexiserver commands if the user has permission via RBAC.