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 privilege.
The only special privilege the "gdm" user requires is the ability to read and write Xauth files to the <var>/lib/gdm directory. The <var>/lib/gdm directory should have root:gdm ownership and 1770 permissions to ensure only the "gdm" user has access to these files.
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 or perform a denial-of-service attack on that session. 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 to 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 initializes 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
mail list, so you can refer to the list archives for more information.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 session:
gdm-autologin session required pam_unix_session.so.1
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.
TODO - Need to update, we changed how Xauth is handled so this section is probably wrong.
Note that NFS traffic really goes "over the wire" and thus can be snooped unless it is tunneled through a secure channel like ssh. 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.
TODO - I believe how Xauth is handled changed a bit, so is the below still correct?
The Xserver authorization directory (<var>/lib/gdm) is used to store 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 Xauth files from this directory.
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.
TODO - is the below still true?
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. So be careful about using remote X display.
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. This is a reasonably secure way to use XDMCP.
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 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 using over the net, and XDMCP is even less safe.
TODO - Should we say more?
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.
GDM may be configured to use RBAC instead of PolicyKit. In this case, RBAC configuration is used to control whether the login screen should provide the shutdown and restart buttons on the greeter screen.
For example, on 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.
TODO - Looking at the code, we now just call g_key_file_load_from_file when loading files from the user's $HOME directory. Is this a bug? Should we be doing some checking to make sure files we open are not links, sockets or devices, etc.? Or was this just over-engineered before and we should just drop this part of the documentation? TODO - I am not really clear on how GDM manages the Xsession file anymore. Someone who understands this should explain. TODO - Is there still a maximum file size or other things that should be explained about how face images are now accessed? Perhaps this section should just go away?
In general GDM is very reluctant regarding reading/writing of user files (such as the ~/.dmrc, ~/.face, ~/.xsession-errors, and ~/.Xauthority files). For instance it refuses to access anything but regular files. Links, sockets and devices are ignored. The value of the RelaxPermissions parameter determines whether GDM should accept files writable by the user's group or others. These are ignored by default.
TODO - UserAuthFBDir is not correct anymore. Need to fix.
All operations on user files are done with the effective user id of the user. If the sanity check fails on the user's .Xauthority file, a fallback cookie is created in the directory specified by the UserAuthFBDir configuration setting (/tmp by default).
Finally, the sysadmin can specify the maximum file size GDM should accept, and, if the face browser is enabled, a tunable maximum icon size is also enforced. On large systems it is still advised to turn off the face browser for performance reasons. Looking up icons in home directories, scaling and rendering face icons can take a long time.