Seguridad

Por razones de seguridad se recomienda un ID de usuario y grupo dedicados para una operación adecuada. Este usuario y grupo generalmente son «gdm» en la mayoría de los sistemas, pero se puede configurar cualquier usuario o grupo. Todos los programas IGU de GDM se ejecutan como este usuario, de tal forma que programas que interactúan con el usuario se ejecutan en una «sandbox». Este usuario y grupo deberían tener privilegios limitados.

El único privilegio especial que requiere el usuario «gdm» es la capacidad de leer y escribir archivos Xauth en la carpeta <var>/run/gdm. La carpeta <var>/run/gdm debería tener un propietario root:gdm y permisos 1777.

No debería, bajo ninguna circunstancia, configurar el usuario/grupo de GDM a un usuario sobre el que se puedan ganar privilegios fácilmente, tal como el usuario nobody. Cualquier usuario que obtiene acceso a una clave Xauth puede fisgar y controlar programas gráficos en ejecución asociados o realizar un ataque de denegación de servicio sobre esa sesión. Es importante asegurarse de que el sistema está configurado de forma correcta de tal forma que sólo el usuario «gdm» tiene acceso a esos archivos y que no es fácil iniciar sesión con esa cuenta. Por ejemplo, la cuenta debería configurarse para no tener contraseña ni permitir que usuarios que no sean root inicien sesión en la cuenta.

La configuración de la interfaz gráfica de GDM se almacena en GConf. Para permitir que el usuario de GDM sea capaz de escribir la configuración es necesario que el usuario «gdm» tenga permiso de escritura sobre la carpeta $HOME. Los usuarios pueden configurar los ajustes predeterminados de GConf como deseen para evitar tener que proporcionar al usuario «gdm» una carpeta $HOME con permisos de escritura. No obstante algunas características de GDM pueden estar desactivadas si no se puede escribir información de estado en la configuración de GConf.

GDM usa PAM para la autenticación del inicio de sesión. PAM significa Pluggable Authentication Module, y lo usan la mayoría de los programas que piden autenticación en su equipo. Permite al administrador configurar diferentes comportamientos de autenticación para distintos programas (tales como SSH, IGU de inicio de sesión, salvapantallas, etc.).

PAM es complicado y muy configurable, además esta documentación no trata de explicarlo en detalle. En su lugar, se intenta proporcionar una visión general de cómo se relaciona la configuración de PAM con GDM, cómo PAM se configura comúnmente con GDM y problemas conocidos. Se espera que una persona que necesite una configuración PAM necesite leer más documentación de PAM para entender cómo configurar PAM y entender términos usados en esta sección.

La configuración PAM tiene interfaces diferentes, pero similares, en los distintos sistemas operativos; compruebe las páginas del manual de pam.d o pam.conf para obtener más detalles. Asegúrese de leer la documentación de PAM y tenga cuidado con las implicaciones de seguridad de cualquier cambio que intente hacer a su configuración.

Tenga en cuenta que, de forma predeterminada, GDM usa el nombre de servicio PAM «gdm» para un inicio de sesión normal y el nombre de servicio PAM «gdm-autologin» para el inicio de sesión automático. Estos servicios pueden no estar definidos en sus archivos de configuración pam.d o pam.conf. Si no hay ninguna entrada, entonces GDM usará el comportamiento predeterminando de PAM. En la mayoría de los sistemas debería funcionar bien. No obstante, la característica de inicio de sesión automático puede no funcionar si el servicio gdm-autologin no está definido.

El script PostLogin se ejecuta antes de llamar a pam_open_session y el script PreSession se llama después. Esto permite al administrador del sistema añadir cualquier script al proceso de inicio de sesión antes o después de que PAM inicialice la sesión.

Si quiere que GDM funciona con otros tipos de mecanismos de autenticación (como una huella digital o un lector de tarjetas SmartCard), entonces debe implementar esto usando un módulo de servicio PAM para el tipo de autenticación requerida en vez de intentando modificar el código de GDM directamente. Consulte la documentación de PAM para su sistema. Esta cuestión se ha discutido en la lista de correo

PAM tiene algunas limitaciones acerca de ser capaz de trabajar con múltiples tipos de autenticación al mismo tiempo, como soportar la capacidad de aceptar tarjetas SmartCard y escribir el usuario y la contraseña en el programa de inicio de sesión. Existen técnicas que se usan para hacer que esto funcione, y es mejor conocer cómo se soluciona comúnmente este problema al establecer tal tipo de configuración.

Si el inicio de sesión automático no funciona en un sistema, compruebe que la pila PAM «gdm-autologin» está definida en la configuración de PAM. Para que esto funcione, si es necesario use un módulo PAM que simplemente no haga autenticación, o que simplemente devuelva PAM_SUCCESS desde todos sus interfaces públicos. Asumiendo que su sistema tiene pam_allow para que el módulo PAM lo haga, una configuración PAM para activara «gdm-autologin» podría ser la siguiente:

    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

La configuración anterior hará que no se genere información de «lastlog». Si quiere una entrada de «lastlog», use lo siguiente para la sesión:

    gdm-autologin session required pam_unix_session.so.1

Si varias personas usan el equipo, lo que hace que el inicio de sesión automático no sea apropiado, puede querer permitir que algunos usuarios inicien sesión sin su contraseña. Esta característica se puede activar como una opción por usuario en la herramienta de usuarios desde las gnome-system-tools; se consigue comprobando que dichos usuarios están en un grupo Unix llamado «nopasswdlogin» antes de preguntar la contraseña. Para que esto funcione el archivo de configuración PAM para el servicio «gdm» debe incluir una línea así:

      gdm auth  sufficient  pam_succeed_if.so  user ingroup nopasswdlogin

GDM genera entradas utmp y wtmp en la base de datos de usuarios sobre el inicio y salida de sesión. La base de datos utmp contiene información del acceso del usuario y de la cuenta y se accede a través de comandos como finger, last, login y who. La base de datos wtmp contiene el histórico de acceso del usuario e información de la cuenta para la base de datos utmp. Para obtener más información consulte las páginas del manual de utmp y wtmp para su sistema operativo.

Los archivos de autorización del servidor X se almacenan en una subcarpeta nueva de <var>/run/gdm creada al inicio. Estos archivos se usan para almacenar y compartir una «contraseña» entre los clientes X y el servidor X. Esta «contraseña» es única para cada inicio de sesión, de tal forma que los usuarios de una sesión no pueden fisgar sobre otros.

GDM sólo soporta el esquema de autenticación del servidor X MIT-MAGIC-COOKIE-1. Normalmente se gana poco con otros esquemas, no se ha hecho ningún esfuerzo en implementarlos hasta ahora. Sea especialmente cuidadoso acerca de usar XDMCP porque la cookie de autenticación del servidor X va sobre el cable en texto plano. Si el espionaje es posible, entonces el atacante podría simplemente espiar su contraseña de autenticación mientras usted inicia una sesión, independientemente del esquema de autenticación que se esté usando. Si el espionaje es posible y no deseable, entonces tendrá que crear un túnel a través de SSH para la conexión X en vez de usar XDMCP. Podría pensar en XDMCP como una clase de Telnet gráfico que tiene los mismos problemas de seguridad. En la mayoría de los casos se debería preferir SSH sobre las características XDMCP de GDM.

Incluso aunque su pantalla esté protegida por cookies, XEvents y las pulsaciones de teclas que se introducen al escribir las contraseñas aún irán sobre el cable en texto claro. Es trivial capturarlas.

XDMCP es útil principalmente para ejecutar clientes ligeros como en terminales de laboratorio. Dichos clientes ligeros sólo necesitarán la red alguna vez para acceder al servidor, y así parece que la mejor política para la seguridad es tener a esos clientes ligeros en una red separada que no pueda accederse desde el mundo exterior, y sólo pueda conectarse al servidor. El único punto desde el que necesita acceder desde fuera es el servidor. Este tipo de configuración nunca debería usar un concentrador no gestionado u otra red que pueda ser vigilada (con un «sniffer»).

El control de acceso XDMCP se realiza usando TCP wrappers. Es posible compilar GDM sin TCP wrappers ya que esta característica puede que no esté soportada en algunos sistemas operativos.

Debería usar el nombre del demonio gdm en el archivo <etc>/hosts.allow y en el archivo <etc>hosts.deny. Por ejemplo para denegar la entrada a equipos de .evil.domain , añada

gdm: .dominio.maligno

a <etc>/hosts.deny. También necesitará añadir

gdm: .su.dominio

a su <etc>/hosts.allow si normalmente no permite todos los servicios desde todos los equipos. Vea la página del manual hosts.allow(5) para más detalles.

Incluso aunque GDM intenta diferenciar inteligentemente a los atacantes potenciales, se recomienda que bloquee el puerto XDMCP (normalmente el puerto UDP 177) en su cortafuegos a no ser que realmente lo necesite. GDM se protege contra ataques de denegación de servicio, pero el protocolo X aún es inherentemente inseguro y sólo debería usarse en entornos controlados. Además cada conexión remota toma muchos recursos, así que es más fácil hacer una denegación de servicios a un servidor XDMCP que a un servidor web.

También es inteligente bloquear todos los puertos del servidor X. Estos puertos son los TCP 6000+ (uno para cada número de pantalla) en el cortafuegos. Note que GDM usará los números de pantalla 20 y superiores para los servidores flexibles bajo demanda.

X no es un protocolo muy seguro para dejarlo en la red, y XDMCP es aún menos seguro.

GDM se puede configurar para usar PolicyKit para permitir al administrador del sistema controlar si la pantalla de inicio de sesión debería proporcionar los botones de apagado y reinicio en la pantalla gráfica con temas.

Estos botones están controlados por las acciones org.freedesktop.consolekit.system.stop-multiple-users y org.freedesktop.consolekit.system.restart-multiple-users respectivamente. Se puede ajustar la política para estas acciones usando la herramienta polkit-gnome-authorization o el programa de línea de comandos polkit-auth.

Se puede configurar GDM para que use RBAC en lugar de PolicyKit. En este caso, la configuración RBAC se usa para controlar si la pantalla de inicio de sesión debería proporcionar los botones de apagado y reinicio en la pantalla gráfica.

Por ejemplo, en Oracle Solaris, la autorización «solaris system shutdown» se usa para controlar esto. Simplemente modifique el archivo /etc/user_attr para que el usuario «gdm» tenga esta autorización.