Security

For security reasons a dedicated user and group ID are recommended for proper operation. This user and group are normally "gdm" on most systems, but can be configured to any user or group. All GDM GUI programs are run as this user, so that the programs which interact with the user are run in a sandbox. This user and group should have limited privileges.

The only special privilege the "gdm" user requires is the ability to read and write Xauth files to the <var>/run/gdm directory. The <var>/run/gdm directory should have root:gdm ownership and 1777 permissions.

You should not, under any circumstances, configure the GDM user/group to a user which a user could easily gain access to, such as the user nobody. Any user who gains access to an Xauth key can snoop on and control running GUI programs running in the associated session or perform a denial-of-service attack on it. It is important to ensure that the system is configured properly so that only the "gdm" user has access to these files and that it is not easy to login to this account. For example, the account should be setup to not have a password or allow non-root users to login to the account.

The GDM greeter configuration is stored in GConf. To allow the GDM user to be able to write configuration, it is necessary for the "gdm" user to have a writable $HOME directory. Users may configure the default GConf configuration as desired to avoid the need to provide the "gdm" user with a writable $HOME directory. However, some features of GDM may be disabled if it is unable to write state information to GConf configuration.

GDM uses PAM for login authentication. PAM stands for Pluggable Authentication Module, and is used by most programs that request authentication on your computer. It allows the administrator to configure specific authentication behavior for different login programs (such as SSH, login GUI, screensaver, etc.)

PAM is complicated and highly configurable, and this documentation does not intend to explain this in detail. Instead, it is intended to give an overview of how PAM configuration relates with GDM, how PAM is commonly configured with GDM, and known issues. It is expected that a person needing to do PAM configuration would need to do further reading of PAM documentation to understand how to configure PAM and to understand terms used in this section.

PAM configuration has different, but similar, interfaces on different Operating Systems, so check the pam.d or pam.conf man page for details. Be sure you read the PAM documentation and are comfortable with the security implications of any changes you intend to make to your configuration.

Note that, by default, GDM uses the "gdm" PAM service name for normal login and the "gdm-autologin" PAM service name for automatic login. These services may not be defined in your pam.d or pam.conf configured file. If there is no entry, then GDM will use the default PAM behavior. On most systems this should work fine. However, the automatic login feature may not work if the gdm-autologin service is not defined.

The PostLogin script is run before pam_open_session is called, and the PreSession script is called after. This allows the system administrator to add any scripting to the login process either before or after PAM initialises the session.

If you wish to make GDM work with other types of authentication mechanisms (such as a fingerprint or SmartCard reader), 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. How to do this is frequently discussed on the

PAM does have some limitations regarding being able to work with multiple types of authentication at the same time, like supporting the ability to accept either SmartCard and the ability to type the username and password into the login program. There are techniques that are used to make this work, and it is best to research how this problem is commonly solved when setting up such a configuration.

If automatic login does not work on a system, check to see if the "gdm-autologin" PAM stack is defined in the PAM configuration. For this to work, it is necessary to use a PAM module that simply does no authentication, or which simply returns PAM_SUCCESS from all of its public interfaces. Assuming your system has a pam_allow.so PAM module which does this, a PAM configuration to enable "gdm-autologin" would look like this:

       gdm-autologin auth  required    pam_unix_cred.so.1
       gdm-autologin auth  sufficient  pam_allow.so.1
       gdm-autologin account  sufficient  pam_allow.so.1
       gdm-autologin session  sufficient  pam_allow.so.1
       gdm-autologin password  sufficient  pam_allow.so.1

The above setup will cause no lastlog entry to be generated. If a lastlog entry is desired, then use the following for the session:

       gdm-autologin session required pam_unix_session.so.1

If the computer is used by several people, which makes automatic login unsuitable, you may want to allow some users to log in without entering their password. This feature can be enabled as a per-user option in the users-admin tool from the gnome-system-tools; it is achieved by checking that the user is member a Unix group called "nopasswdlogin" before asking for a password. For this to work, the PAM configuration file for the "gdm" service must include a line such as:

      gdm auth  sufficient  pam_succeed_if.so  user ingroup nopasswdlogin

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. Refer to the utmp and wtmp man pages on your system for more information.

Xserver authorization files are stored in a newly created subdirectory of <var>/run/gdm at start up. These files are used to store and share a "password" between X clients and the Xserver. This "password" is unique for each session logged in, so users from one session can't snoop on users from another.

GDM only supports the MIT-MAGIC-COOKIE-1 Xserver 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 Xserver 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. In most cases, ssh -Y should be preferred over GDM's XDMCP features.

Even though your display is protected by cookies, XEvents and keystrokes typed when entering passwords will still go over the network 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. This type of set up should never use an unmanaged hub or other sniffable network.

XDMCP access control is done using TCP wrappers. It is possible to compile GDM without TCP wrapper support, so this feature may not be supported on some Operating Systems.

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.

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 really needed. GDM guards against 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 do a denial of service attack via XDMCP than attacking a webserver.

It is also wise to block all of the Xserver ports. These are TCP ports 6000+ (one for each display number) 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 when using it over the Internet, and XDMCP is even less safe.

GDM may be configured to use PolicyKit to allow the system administrator to control whether the login screen should provide the shutdown and restart buttons on the greeter screen.

These buttons are controlled by the org.freedesktop.consolekit.system.stop-multiple-users and org.freedesktop.consolekit.system.restart-multiple-users actions respectively. Policy for these actions can be set up using the polkit-gnome-authorization tool, or the polkit-auth command line program.

GDM may be configured to use RBAC instead of PolicyKit. In this case the RBAC configuration is used to control whether the login screen should provide the shutdown and restart buttons on the greeter screen.

For example, on Oracle Solaris, the "solaris.system.shutdown" authorization is used to control this. Simply modify the /etc/user_attr file so that the "gdm" user has this authorization.