Security

GDM uses PAM for username/authentication, though if your machine does not support PAM you can build GDM to work with shadow passwords and crypt.

PAM stands for Pluggable Authentication Module, and is used by most programs that request username/password authentication on your computer. It allows the user 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 has different, but similar, interfaces on different operating systems, so check your pam.d or pam.conf man page for details about how to configure it. Make sure to read the PAM documentation (e.g. pam.d/pam.conf man page) and be 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 tomatic login may not work. Not having an entry will causes 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 writing a PAM module 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

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.

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.

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.

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.

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 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.