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