3.1. The GDM User And Group
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>/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 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
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
3.3. utmp and 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. Refer to the utmp and wtmp man pages on your system for more information.
3.4. Xserver Authentication Scheme
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.
3.5. 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. This type of set up should never use an unmanaged hub or other sniffable network.
3.6. XDMCP Access Control
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
to <etc>/hosts.deny. You may also need to add
to your <etc>/hosts.allow if you normally disallow all services from all hosts. See the hosts.allow(5) man page for details.
3.7. 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 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.
3.9. RBAC (Role Based Access Control)
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.
- Copyright © 1998, 1999 Martin K. Petersen
- Copyright © 2001, 2003, 2004 George Lebl
- Copyright © 2003, 2007, 2008 Red Hat, Inc.
- Copyright © 2003, 2011 Oracle and/or its affiliates. All rights reserved.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License (GFDL), Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. You can find a copy of the GFDL at this link or in the file COPYING-DOCS distributed with this manual.
This manual is part of a collection of GNOME manuals distributed under the GFDL. If you want to distribute this manual separately from the collection, you can do so by adding a copy of the license to the manual, as described in section 6 of the license.
Many of the names used by companies to distinguish their products and services are claimed as trademarks. Where those names appear in any GNOME documentation, and the members of the GNOME Documentation Project are made aware of those trademarks, then the names are in capital letters or initial capital letters.
DOCUMENT AND MODIFIED VERSIONS OF THE DOCUMENT ARE PROVIDED UNDER THE TERMS OF THE GNU FREE DOCUMENTATION LICENSE WITH THE FURTHER UNDERSTANDING THAT:
- DOCUMENT IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE DOCUMENT OR MODIFIED VERSION OF THE DOCUMENT IS FREE OF DEFECTS MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING. THE ENTIRE RISK AS TO THE QUALITY, ACCURACY, AND PERFORMANCE OF THE DOCUMENT OR MODIFIED VERSION OF THE DOCUMENT IS WITH YOU. SHOULD ANY DOCUMENT OR MODIFIED VERSION PROVE DEFECTIVE IN ANY RESPECT, YOU (NOT THE INITIAL WRITER, AUTHOR OR ANY CONTRIBUTOR) ASSUME THE COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF ANY DOCUMENT OR MODIFIED VERSION OF THE DOCUMENT IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER; AND
- UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, WHETHER IN TORT (INCLUDING NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL THE AUTHOR, INITIAL WRITER, ANY CONTRIBUTOR, OR ANY DISTRIBUTOR OF THE DOCUMENT OR MODIFIED VERSION OF THE DOCUMENT, OR ANY SUPPLIER OF ANY OF SUCH PARTIES, BE LIABLE TO ANY PERSON FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF GOODWILL, WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER DAMAGES OR LOSSES ARISING OUT OF OR RELATING TO USE OF THE DOCUMENT AND MODIFIED VERSIONS OF THE DOCUMENT, EVEN IF SUCH PARTY SHALL HAVE BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGES.