<?xml version="1.0"?>
<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Security</title><link rel="previous" href="overview.xhtml" title="Overview"/><link rel="next" href="gdmsetupusage.xhtml" title="Using gdmsetup To Configure GDM"/><link rel="top" href="index.xhtml" title="Gnome Display Manager Reference Manual"/><style>
div[class~="footnotes"] {
font-style: italic;
font-size: 0.8em;
}
div[class~="footnote"] {
margin-top: 1.44em;
}
span[class~="footnote-number"] {
display: inline;
padding-right: 0.83em;
}
span[class~="footnote-number"] + p {
display: inline;
}
a[class~="footnote"] {
text-decoration: none;
font-size: 0.8em;
}
a[class~="footnote-ref"] {
text-decoration: none;
}
div[class~="caution"] {
background-image: url("caution.png");
}
div[class~="important"] {
background-image: url("important.png");
}
div[class~="note"] {
background-image: url("note.png");
}
div[class~="tip"] {
background-image: url("tip.png");
}
div[class~="warning"] {
background-image: url("warning.png");
}
div[class~="admonition"] {
padding-top: 4px;
padding-bottom: 4px;
padding-left: 56px;
padding-right: 8px;
min-height: 52px;
border: dotted #D1940C 1px;
background-position: 4px 4px;
background-repeat: no-repeat;
}
div[class~="autotoc"] { margin-left: 2em; padding: 0em; }
div[class~="autotoc"] ul { margin-left: 0em; padding-left: 0em; }
div[class~="autotoc"] ul li {
margin-right: 0em;
padding: 0em;
list-style-type: none;
}
* + div[class~="biblioentry"] { margin-top: 1.2em; }
* + div[class~="bibliomixed"] { margin-top: 1.2em; }
*[class~="block-indent"] {
margin-left: 1.72em;
margin-right: 1em;
}
*[class~="block-indent"] *[class~="block-indent"] {
margin-left: 0em;
margin-right: 0em;
}
*[class~="block-verbatim"] {
white-space: pre;
}
pre[class~="programlisting"] {
padding: 6px;
-moz-border-radius: 8px;
overflow: auto;background-color: #EEEEEE;border: solid 1px #DDDDDD
}
pre[class~="screen"] {
padding: 6px;
-moz-border-radius: 8px;
overflow: auto;background-color: #EEEEEE;border: solid 1px #DDDDDD
}
pre[class~="synopsis"] {
overflow: auto;
}
pre[class~="linenumbering"] {
padding-top: 6px;
padding-bottom: 6px;
-moz-border-radius: 8px;
border: solid 1px black;
margin-top: 0px;
margin-left: 0.83em;
background-color: black;
color: white;
-moz-opacity: .3;
padding-right: 0.4em;
padding-left: 0.4em;
}
dt[class~="glossterm"] { margin-left: 0em; }
dd + dt[class~="glossterm"] { margin-top: 2em; }
dd[class~="glossdef"]
{ margin-top: 1em; margin-left: 2em; margin-right: 1em; }
dd[class~="glosssee"]
{ margin-top: 1em; margin-left: 2em; margin-right: 1em; }
dd[class~="glossseealso"]
{ margin-top: 1em; margin-left: 2em; margin-right: 1em; }
span[class~="co"] {
font-size: 8px;
padding-left: 0.4em;
padding-right: 0.4em;
margin-left: 0.2em;
margin-right: 0.2em;
border: solid 1px;
-moz-border-radius: 8px;
color: #FFFFFF;
background-color: #000000;
border-color: #000000;
}
span[class~="co"]:hover {
color: #FFFFFF;
background-color: #333333;
border-color: #333333;
}
span[class~="co"] a { text-decoration: none; }
span[class~="co"] a:hover { text-decoration: none; }
div[class~="cmdsynopsis"] { font-family: monospace; }
div[class~="list"] { margin-left: 0px; padding: 0px; margin-bottom: 1em; }
div[class~="list"] dl dt { margin-left: 0em; }
div[class~="list"] dl dd + dt { margin-top: 1em; }
div[class~="list"] dl dd {
margin-top: 0.69em;
margin-left: 1.72em;
margin-right: 1em;
}
div[class~="list"] ul { margin-left: 1.72em; padding-left: 0em; }
div[class~="list"] ol { margin-left: 1.72em; padding-left: 0em; }
div[class~="list"] ul li { margin-right: 1em; padding: 0em; }
div[class~="list"] ol li { margin-right: 1em; padding: 0em; }
div[class~="list"] li + li { margin-top: 0.69em; }
div[class~="simplelist"] > table { border: none; }
dt[class~="question"] { margin-left: 0em; }
dt[class~="question"] div[class~="label"] { float: left; }
dd + dt[class~="question"] { margin-top: 1em; }
dd[class~="answer"] {
margin-top: 1em;
margin-left: 2em;
margin-right: 1em;
}
dd[class~="answer"] div[class~="label"] { float: left; }
div[class~="refentry"] h2[class~="refentry"] {
border: none;
margin-top: 1em;
}
div[class~="refentry"] + div[class~="refentry"] {
border-top: dashed black 1px;
}
table {
border-collapse: collapse;
border: solid 1px;
-moz-border-radius: 5px;
}
tr[class~="odd"] { background-color: #F0F0F0 }
td {
padding-left: 0.83em;
padding-right: 0.83em;
padding-top: 4px;
padding-bottom: 4px;
}
th { padding-left: 0.8em; padding-right: 0.83em; }
thead {
border-top: solid 2px;
border-bottom: solid 2px;
}
tfoot {
border-top: solid 2px;
border-bottom: solid 2px;
}
td + td {
border-left: solid 1px;
}
tbody {
border: solid 1px;
-moz-border-radius: 5px;
}
h1 { font-size: 1.72em; margin-top: 0em; }
h2 { font-size: 1.44em; }
h2[class~="title"] { margin-top: 1.72em; border-bottom: solid 1px; }
h3 { font-size: 1.2em; }
h3[class~="title"] { margin-top: 1.72em; }
h3 span[class~="title"] { border-bottom: solid 1px; }
h4 { font-size: 1.0em; }
h4[class~="title"] { margin-top: 1.44em; }
h4 span[class~="title"] { border-bottom: solid 1px; }
h5 { font-size: 1em; margin-top: 1em; }
h6 { font-size: 1em; margin-top: 1em; }
h7 { font-size: 1em; margin-top: 1em; }
body {
margin: 0px;
direction: ltr;
}
div[class ~= "body"] {
padding: 12px;
}
div[class ~= "navbar"] {
margin-left: 12px;
margin-right: 12px;
margin-bottom: 12px;
padding: 6px;
border: solid 1px;
}
div[class ~= "navbar-prev"] {
margin: 0px;
padding: 0px;
float: left;
}
div[class ~= "navbar-prev-sans-next"] {
float: none;
}
div[class ~= "navbar-next"] {
margin: 0px;
padding: 0px;
text-align: right;
}
div {
margin-top: 0em; margin-bottom: 0em;
padding-top: 0em; padding-bottom: 0em;
}
p {
margin-top: 0em; margin-bottom: 0em;
padding-top: 0em; padding-bottom: 0em;
}
div + * { margin-top: 1em; }
p + * { margin-top: 1em; }
p > div { margin-top: 1em; margin-bottom: 1em; }
p > div + div { margin-top: 0em; }
p { text-align: justify; }
</style></head><body><div class="body"><div class="sect1"><a name="security"/><h1 class="sect1 title"><span class="title">Security</span></h1><div class="sect2"><a name="PAM"/><h2 class="sect2 title"><span class="title"><span class="label">3.1. </span>
PAM
</span></h2><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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 causes GDM to use default behavior, conservative settings are
recommended and probably shipped with your distribution.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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
<div class="address block-verbatim"><span class="email-punc"><tt><<a href="mailto:gdm-list@gnome.org" title="Send email to ‘’."><span class="email">gdm-list@gnome.org</span></a>></tt></span></div> mail list,
so you can refer to the list archives for more information.
</p></div><div class="sect2"><a name="gdmuser"/><h2 class="sect2 title"><span class="title"><span class="label">3.2. </span>The GDM User</span></h2><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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 <span class="command" style="font-family: monospace; ">gdmgreeter</span> and
<span class="command" style="font-family: monospace; ">gdmlogin</span>. These are configured via the
<span class="filename" style="font-family: monospace; ">User</span> and <span class="filename" style="font-family: monospace; ">Group</span>
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".
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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 <span class="filename" style="font-family: monospace; "><var>/lib/gdm</span>.
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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 <span class="filename" style="font-family: monospace; ">nobody</span>. 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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p></div><div class="sect2"><a name="xauth"/><h2 class="sect2 title"><span class="title"><span class="label">3.3. </span>X Server Authentication Scheme</span></h2><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
The X server authorization directory (the
<span class="filename" style="font-family: monospace; ">ServAuthDir</span>) 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 <span class="filename" style="font-family: monospace; ">root.gdm</span> 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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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 <span class="filename" style="font-family: monospace; ">/dev/audio</span> or
<span class="filename" style="font-family: monospace; ">/dev/mem</span> 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
<span class="filename" style="font-family: monospace; ">UserAuthDir</span> configuration key). So be careful
about where you use remote X display.
</p></div><div class="sect2"><a name="firewall"/><h2 class="sect2 title"><span class="title"><span class="label">3.4. </span>Firewall Security</span></h2><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
X is not a very safe protocol for leaving on the net, and XDMCP is
even less safe.
</p></div><div class="sect2"><a name="nfssecurity"/><h2 class="sect2 title"><span class="title"><span class="label">3.5. </span>GDM Security With NFS</span></h2><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
Note that NFS traffic really goes "over the wire" and thus
can be snooped. When accessing the user's X authorization file
(<span class="filename" style="font-family: monospace; ">~/.Xauthority</span>), 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
<span class="filename" style="font-family: monospace; ">UserAuthFBDir</span>, which by default is set to
<span class="filename" style="font-family: monospace; ">/tmp</span>. This behavior can be changed by setting the
<span class="filename" style="font-family: monospace; ">NeverPlaceCookiesOnNFS</span> in the
<span class="filename" style="font-family: monospace; ">[security]</span> section to false.
</p></div><div class="sect2"><a name="xdmcpsecurity"/><h2 class="sect2 title"><span class="title"><span class="label">3.6. </span>XDMCP Security</span></h2><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p></div><div class="sect2"><a name="xdmcpaccess"/><h2 class="sect2 title"><span class="title"><span class="label">3.7. </span>XDMCP Access Control</span></h2><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
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.
</p><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
You should use the daemon name <span class="command" style="font-family: monospace; ">gdm</span> in the
<span class="filename" style="font-family: monospace; "><etc>/hosts.allow</span> and
<span class="filename" style="font-family: monospace; "><etc>/hosts.deny</span> files. For example to
deny computers from <span class="filename" style="font-family: monospace; ">.evil.domain</span> from logging in,
then add
</p><div xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="screen block-indent"><pre class="screen">gdm: .evil.domain
</pre></div><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
to <span class="filename" style="font-family: monospace; "><etc>/hosts.deny</span>. You may also need
to add
</p><div xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="screen block-indent"><pre class="screen">gdm: .your.domain
</pre></div><p xmlns:msg="http://www.gnome.org/~shaunm/gnome-doc-utils/l10n" class="para">
to your <span class="filename" style="font-family: monospace; "><etc>/hosts.allow</span> if you normally
disallow all services from all hosts. See the
<a class="ulink" href="man:hosts.allow" title="man:hosts.allow">hosts.allow(5)</a> man
page for details.
</p></div></div></div><div class="navbar"><div class="navbar-prev"><span class="navbar-prev"><a class="navbar navbar-prev" href="overview.xhtml" title="Overview">Overview</a></span></div><div class="navbar-next"><span class="navbar-next"><a class="navbar navbar-next" href="gdmsetupusage.xhtml" title="Using gdmsetup To Configure GDM">Using gdmsetup To Configure GDM</a></span></div></div></body></html>
