Seguranza

3.1. O usuario e grupo de GDM

Por razóns de seguranza recoméndase ter un id de usuario e group para que funcione correctamente a operación. Este usuario e grupo son «gdm» na maioría dos sistemas normalmente, aínda que poden configurarse para calquera usuario ou grupo. Todos os programs de GUI de GDM executaranse con este usuario, polo que os programas que interactúan con este usuario son executados nunha caixa de area. Este usuario e grupo deberían ter privilexios limitados.

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.

3.2. PAM

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.

A configuración PAM ten interfaces diferentes, pero similares, para os distintos sistemas operativos, polo que comprobe a páxina man pam.d ou pam.conf. Asegúrese que lee a documentación PAM e ten en conta as implicacións de seguridade que calquera cambio que queira facer na súa configuración.

Teña en conta que, por omisión, GDM usa o nome de servizo PAM «gdm» para o inicio de sesión normal e o nome de servizo PAM «gdm-autologin» para os inicios de sesión automáticos. Se non hai entrada entón GDM usará o comportamento PAM por omisión. Na maioría dos sistemas isto funcionará ben, porén, no inicio de sesión automático pode que non funcione se o servizo gdm-autologin non está definido.

O script PostLogin execútase antes de que se chame a pam_open_session, e o script PreSession chámase despois. Isto permítelle ao administrador do sistema engadir calquera script no proceso de inicio de sesión antes ou despois de que PAM inicialice a sesión.

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

A configuración de arriba causará que a entrada lastlog non se xere. Se desexa unha entrada lastlog entón use o seguinte para a sesión:

       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. Esquema de autenticación do servidor X

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

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. Control de acceso XDMCP

O control de acceso de XDMCP está construído empregando envoltorios de TCP. É posíbel compilar GDM sen a compatibilidade de envoltorios de TCP, polo que esta característica podería non admitirse nalgúns sistemas operativos.

Debería usar un nome de daemon gdm nos ficheiros <etc>/hosts.allow e <etc>/hosts.deny. Por exemplo para denegarlle o inicio de sesión desde .dominio.maligno, entón engada

gdm: .dominio.maligno

a <etc>/hosts.deny. Tamén precisa engadir

gdm: .o.seu.dominio

ao seu <etc>/hosts.allow se normalmente desautoriza todos os servizos desde todos os equipos. Vexa unha páxina d eman hosts.allow(5) para obter máis detalles.

3.7. Seguranza con devasa

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 non é un protocolo moi seguro ao usalo por internet, e XDMCP é aínda menos seguro.

3.8. PolicyKit

GDM pode configurarse para usar PolicyKit para permitirlle a un administrador de sistemas o control de se a pantalla de benvida debería fornecer os botóns de apagado e reinicio.

Estes botóns están controlados polas accións org.freedesktop.consolekit.system.stop-multiple-users e org.freedesktop.consolekit.system.restart-multiple-users respectivamente. A normativa para estas acccións pode configurarse usando a ferramenta polkit-gnome-authorization ou o programa de liña de ordes polkit-auth.

3.9. RBAC (Control de acceso baseado en rol)

GDM pode configurarse para usar RBAC no lugar de PolicyKit. Neste caso a configuración de RBAC úsase para controlar se a pantalla de inicio de sesión debería fornecer os botóns de apagado e reinicio na pantalla de benvida.

Por exemplo, en Oracle Soraris, úsase a autorización «solaris.system.shutdown» para controlar isto. Simplemente modifique o ficheiro /etc/user_attr para que o usuario «gdm» teña esta autorización.