Seguretat
- 3.1. L'usuari i grup del GDM
- 3.2. PAM
- 3.3. utmp i wtmp
- 3.4. Esquema d'autenticació del servidor d'X
- 3.5. Seguretat de l'XDMCP
- 3.6. Control d'accés de l'XDMCP
- 3.7. Seguretat del tallafoc
- 3.8. PolicyKit
- 3.9. RBAC (control d'accés basat en el rol)
3.1. L'usuari i grup del GDM
Per raons de seguretat es recomana un identificador d'usuari i de grup específic pel correcte funcionament. A la majoria de sistemes aquest usuari i grup normalment és el «gdm», però pot ser qualsevol usuari o grup. Tots els programes d'interfície gràfica d'usuari del GDM s'executen amb aquest usuari, de manera que els programes que interactuen amb l'usuari s'executen en un entorn aïllat. L'usuari i el grup haurien de tenir els privilegis limitats.
L'únic privilegi especial que necessita l'usuari «gdm» és la capacitat de llegir i escriure fitxers Xauth al directori <var>/run/gdm. El propietari del directori <var>/run/gdm hauria de ser root i del grup gdm amb els permisos 1777.
No hauríeu, baix cap concepte, de configurar l'usuari/grup del GDM a un usuari sobre el qual un usuari pogués guanyar-ne fàcilment accés, com ara l'usuari nobody. Qualsevol usuari que guanyi accés a una clau Xauth pot tafanejar i controlar programes en execució de la interfície gràfica d'usuari associats a la sessió, o realitzar-hi un atac de denegació de servei. És important assegurar-se que el sistema està configurat adequadament de manera que només l'usuari «gdm» té accés a aquests fitxers i que no és fàcil entrar a aquest compte. Per exemple, el compte s'hauria de configurar perquè no tingui contrasenya o no permetre que usuaris no primaris puguin entrar-hi.
La configuració del rebedor del GDM s'emmagatzema al GConf. Per permetre que l'usuari GDM pugui escriure la configuració, és necessari que l'usuari «gdm» tingui un directori d'usuari amb permisos d'escriptura. Els usuaris poden configurar la configuració per defecte del GConf com desitgin per evitar la necessitat de proporcionar a l'usuari «gdm» un directori d'usuari amb permisos d'escriptura. Tot i això, es poden inhabilitar algunes funcions del GDM si no es pot escriure informació d'estat a la configuració del GConf
3.2. PAM
El GDM utilitza el PAM per a l'autenticació d'entrada. PAM significa mòduls de connectors d'autenticació (Pluggable Authentication Modules) i l'utilitzen la majoria de programes que sol·liciten autenticació a l'ordinador. Això permet a l'administrador configurar els comportaments d'autenticació específics per diferents programes d'entrada (com ara el ssh, la interfície gràfica d'entrada, l'estalvi de pantalla, etc.)
El PAM és complicat i altament configurable i en aquesta documentació no s'intenta d'explicar-lo amb pèls i senyals. La idea és donar una visió global de com afecta la configuració del PAM al GDM, com es configura normalment el PAM amb el GDM i els problemes coneguts. S'espera que qui hagi de realitzar una configuració del PAM llegirà més documentació del PAM per entendre com configurar-lo i entendre'n els termes utilitzats en aquesta secció.
La configuració del PAM te interfícies diferents, però similars, segons el sistema operatiu, de manera que comproveu les pàgines del manual del pam.d o del pam.conf per obtenir-ne tots els detalls. Assegureu-vos que llegiu la documentació del PAM i que esteu segurs de les implicacions de seguretat que qualsevol canvi que intenteu realitzar a la configuració pot ocasionar.
Tingueu en compte que, per defecte, el GDM utilitza el nom de servei del PAM «gdm» per a una entrada normal i el nom de servei del PAM «gdm-autologin» per a una entrada automàtica. Pot ser que aquests serveis no estiguin definits al fitxer de configuració pam.d o pam.conf. Si no hi ha cap entrada el GDM utilitzarà el comportament per defecte del PAM. A la majoria de sistemes aquest hauria de funcionar sense cap problema. Tot i això, la funció d'entrada automàtica podria no funcionar si el servei gdm-autologin no està definit.
L'script PostLogin s'executa abans de cridar pam_open_session i l'script PreSession després. Això permet a l'administrador del sistema afegir qualsevol script al procés d'entrada abans o després que el PAM iniciï la sessió.
Si voleu fer que el GDM funcioni amb altres tipus de mecanismes d'autenticació (com ara una empremta dactilar o un lector de targetes SmartCard), llavors hauríeu d'implementar-ho utilitzant un mòdul de servei del PAM per al tipus d'autenticació desitjat en comptes d'intentar modificar el codi del GDM directament. Consulteu la documentació del PAM del sistema. Se'n parla sovint a la llista de correu
, de manera que podeu consultar els arxius de la llista per saber-ne més.El PAM té algunes limitacions relacionades en ser capaç de treballar amb diversos tipus d'autenticació a la vegada, admetre l'habilitat d'acceptar targetes SmartCard i introduir el nom d'usuari i la contrasenya al programa d'entrada. S'utilitzen diverses tècniques per fer que això funcioni i és una bona idea conèixer-les si es vol utilitzar una configuració semblant.
Si a un sistema no funciona l'entrada automàtica, comproveu si la pila del PAM «gdm-autologin» està definida a la configuració del PAM. Per fer-ho funcionar, és necessari utilitzar un mòdul del PAM que simplement no faci autenticació o que simplement retorni PAM_SUCCESS des de totes les interfícies públiques. Si s'assumeix que el sistema té un mòdul del PAM pam_allow.so que fa això, una configuració del PAM per habilitar el «gdm-autologin» podria ser aquesta:
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ó anterior provocarà que no es generi cap entrada de lastlog. Si voleu una entrada de lastlog, llavors utilitzeu el següent per a la sessió:
gdm-autologin session required pam_unix_session.so.1
Si l'ordinador l'empren diferents persones, el que fa inviable l'inici automàtic de sessió, podeu permetre que algun usuari accedeixi sense contrasenya. Aquesta característica es pot habilitar a nivell d'usuari amb l'eina users-admin del gnome-system-tools; s'aconsegueix verificant abans de demanar la contrasenya si l'usuari és membre del grup Unix «nopasswdlogin». Per a què funcioni, el fitxer de configuració del PAM pel servei «gdm» ha d'incloure una línia com aquesta:
gdm auth sufficient pam_succeed_if.so user ingroup nopasswdlogin
3.3. utmp i wtmp
El GDM genera entrades utmp i wtmp a la base de dades de comptes d'usuari quan l'usuari entra i surt de la sessió. La base de dades utmp conté informació de l'accés de l'usuari i del compte que hi accedeixen ordres com ara el finger, el last, el login i el who. La base de dades wtmp conté l'historial de la informació de l'accés de l'usuari i del compte per a la base de dades utmp. Per obtenir més informació consulteu les pàgines del manual del sistema utmp i wtmp.
3.4. Esquema d'autenticació del servidor d'X
Els fitxers d'autorització del servidor d'X s'emmagatzemen en un subdirectori nou a <var>/run/gdm que es crea a l'inici. Els fitxers serveixen per emmagatzemar i compartir una «contrasenya» entre els clients d'X i el servidor d'X. Aquesta «contrasenya» és única per a cada sessió d'entrada, de manera que els usuaris d'una sessió no poden tafanejar a usuaris d'una altra.
El GDM només admet l'esquema d'autenticació MIT-MAGIC-COOKIE-1 del servidor d'X. La resta d'esquemes no aporten gairebé cap benefici, de manera que no s'ha realitzat cap esforç per implementar-los. Vigileu especialment la utilització de l'XDMCP perquè les galetes d'autenticació del servidor d'X circulen per la xarxa com a text pla. Si és possible tafanejar, llavors un atacant podria simplement tafanejar la vostra contrasenya d'autenticació quan entreu, independentment de l'esquema d'autenticació que s'utilitzes. Si és possible tafanejar però no és desitjable, llavors hauríeu d'utilitzar l'SSH per fer una tunelització d'una connexió d'X en comptes d'utilitzar l'XDMCP. Podeu pensar que l'XDMCP és una espècie de telnet gràfic, que té els mateixos problemes de seguretat. En la majoria de casos, s'hauria de fer servir l'SSH -Y en comptes de les funcions XDMCP del GDM.
3.5. Seguretat de l'XDMCP
Encara que la pantalla està protegida per galetes, els XEvents i les pulsacions de tecles quan s'introdueix la contrasenya encara circularan per la xarxa com a text pla. És trivial capturar-les.
L'XDMCP és útil principalment per executar clients lleugers com ara en terminals de laboratori. Aquests clients lleugers només necessiten la xarxa per accedir al servidor i per tant sembla que la millor política de seguretat és tenir aquests clients lleugers en una xarxa separada a la qual no es pot accedir des del món exterior i només es pot connectar al servidor. L'únic punt des d'on necessiteu accedir a fora és el servidor. Aquest tipus de configuració no hauria d'utilitzar un concentrador no gestionat o una altre xarxa que es pugui vigilar.
3.6. Control d'accés de l'XDMCP
El control d'accés de l'XDMCP es realitza utilitzant embolcalls TCP. És possible compilar el GDM sense la compatibilitat d'embolcalls TCP, de manera que aquesta funció potser no està disponible en alguns sistemes operatius.
Hauríeu d'utilitzar el nom del dimoni gdm als fitxers <etc>/hosts.allow i <etc>/hosts.deny. Per exemple, per denegar l'entrada d'ordinadors des de .evil.domain heu d'afegir
gdm: .evil.domain
a <etc>/hosts.deny. També heu d'afegir
gdm: .your.domain
al vostre <etc>/hosts.allow si normalment no permeteu tots els serveis des de tots els amfitrions. Per obtenir més detalls vegeu la pàgina del manual hosts.allow(5).
3.7. Seguretat del tallafoc
Encara que el GDM intenta diferenciar intel·ligentment atacants potencials utilitzant l'avantatge de l'XDMCP, encara es recomana que bloquegeu el port de l'XDMCP (normalment el port UDP 177) del tallafoc a no ser que realment el necessiteu. El GDM es protegeix contra atacs de denegació de servei, però el protocol d'X encara és inherentment insegur i només s'hauria d'utilitzar en entorns controlats. A més cada connexió remota utilitza molts recursos, de manera que és molt més fàcil realitzar un atac de denegació de servei mitjançant l'XDMCP que atacar un servidor web.
També es recomana bloquejar al tallafoc tots els ports del servidor d'X (aquests són els ports TCP 6000 + el número de la pantalla). Tingueu en compte que el GDM utilitzarà els números de pantalla 20 i superiors per als servidors sota demanda flexibles.
L'X no és un protocol molt segur per utilitzar-se per Internet i l'XDMCP ho és encara menys.
3.8. PolicyKit
Es pot configurar el GDM perquè utilitzi el PolicyKit per permetre a l'administrador del sistema controlar quan la pantalla d'entrada hauria de proporcionar els botons d'apagar i de tornar a iniciar a la pantalla del rebedor.
Les accions org.freedesktop.consolekit.system.stop-multiple-users i org.freedesktop.consolekit.system.restart-multiple-users controlen aquests botons respectivament. Es pot ajustar la política les accions amb l'eina polkit-gnome-authorization o el programa de línia d'ordres polkit-auth.
3.9. RBAC (control d'accés basat en el rol)
El GDM es pot configurar perquè utilitzi el RBAC en comptes del PolicyKit. En aquest cas, s'utilitza la configuració del RBAC per controlar quan la pantalla d'entrada hauria de proporcionar els botons d'apagar i de tornar a iniciar a la pantalla del rebedor.
Per exemple, a l'Oracle Solaris, s'utilitza l'autorització «solaris.system.shutdown» per controlar-ho. Només cal que modifiqueu el fitxer /etc/user_attr de manera que l'usuari «gdm» tingui aquesta autorització.