Säkerhet
- 3.1. GDM-användaren och -gruppen
- 3.2. PAM
- 3.3. utmp och wtmp
- 3.4. Xserver-autentiseringssystem
- 3.5. XDMCP-säkerhet
- 3.6. XDMCP tillgångskontroll
- 3.7. Brandväggssäkerhet
- 3.8. PolicyKit
- 3.9. RBAC (Roll-baserad tillgångskontroll)
3.1. GDM-användaren och -gruppen
Av säkerhetsskäl rekommenderas ett särskilt konto- och grupp-id för korrekt funktion. Denna användare och grupp är normalt ”gdm” på de flesta system, men kan konfigureras till godtycklig användare eller grupp. Alla GDM GUI-program körs som denna användare så program som interagerar med användaren körs i en sandlåda. Denna användare och grupp bör ha begränsade privilegier.
Det enda speciella privilegium som ”gdm”-användaren kräver är möjligheten att läsa och skriva Xauth-filer i katalogen <var>/run/gdm. <var>/run/gdm-katalogen bör ha root:gdm-ägandeskap och 1777-rättigheter.
Du bör inte, under några omständigheter, konfigurera GDM-användaren/-gruppen till en användare som en användare lätt kan få tag i, så som användaren nobody. Den användare som får tillgång till en Xauth-nyckel kan snoka på och kontrollera körande GUI-program som körs i den associerade sessionen eller utföra överbelastningsattacker på den. Det är viktigt att säkerställa att systemet är konfigurerat korrekt så att bara ”gdm”-användaren har tillgång till dessa filer och att det inte är lätt att logga in på detta konto. Till exempel bör kontot vara inställt på att inte ha något lösenord eller låta icke-root-användare logga in på kontot.
GDM-inloggningsskärmens konfiguration sparas i GConf. För att låta GDM-användaren kunna skriva konfigurationen är det nödvändigt för ”gdm”-användaren att ha en skrivbar $HOME-katalog. Användare kan konfigurera standard GConf-konfigurationen som önskas för att undvika att ge ”gdm”-användaren en skrivbar $HOME-katalog. Vissa GDM-funktioner kommer dock att vara inaktiverade om det inte kan skriva tillståndsinformation till GConf-konfigurationen.
3.2. PAM
GDM använder PAM för inloggningsautentisering. PAM står för Pluggable Authentication Module och används av de flesta program som begär autentisering på din dator. Det låter administratören konfigurera specifika autentiseringsbeteenden för olika inloggningsprogram (t.ex. ssh, login GUI, skärmsläckaren, etc.).
PAM är komplicerat och väldigt konfigurerbart och detta dokument avser inte att förklara detta i detalj. Istället avser det att ge en överblick över hur PAM-konfiguration knyts samman med GDM, hur PAM vanligtvis är konfigurerat tillsammans med GDM och kända problem. Det förväntas att en person som behöver göra PAM-konfigurering behöver läsa vidare i PAM-dokumentationen för att förstå hur man konfigurerar PAM och förstå terminologin i detta avsnitt.
PAM-konfiguration har olika, men liknande, gränssnitt på olika operativsystem, så kontrollera manualsidorna pam.d eller pam.conf för vidare detaljer. Se till att du läser PAM-dokumentationen och är bekväm med säkerhetskonsekvenserna av ändringar som du avser att göra i din konfiguration.
Notera att GDM som standard använder PAM-tjänstnamnet ”gdm” för normal inloggning och PAM-tjänstnamnet ”gdm-autologin” för automatisk inloggning. Dessa tjänster kanske inte finns definierade i din pam.d eller pam.conf konfigurationsfil. Om en post saknas, kommer GDM att använda PAM:s standardbeteende. På de flesta system borde detta fungera bra. Men den automatiska inloggningsfunktionen kanske inte fungerar om gdm-autologin-tjänsten inte är definierad.
Skriptet PostLogin körs före pam_open_session anropas, och skriptet PreSession körs efteråt. Detta låter systemadministratören lägga till godtycklig skriptning till inloggningsprocessen antingen innan eller efter att PAM initierar sessionen.
Om du önskar att få GDM att fungera med andra typer av autentiseringsmekanismer (som fingeravtryck eller SmartCard-läsare) så bör du implementera detta genom att använda en PAM-modul för den önskade autentiseringstypen snarare än att försöka modifiera GDM-koden direkt. Se vidare i PAM-dokumentation på ditt system. Hur du ska göra detta diskuteras ofta på sändlistan
, så du kan läsa i listarkiven för vidare information.PAM har några begränsningar angående att fungera tillsammans med flera typer av autentisering samtidigt, så som att acceptera antingen ett SmartCard eller möjligheten att mata in användarnamn och lösenord i inloggningsprogrammet. Det finns tekniker för att få detta att fungera, och det är bäst att ta reda på hur detta problem vanligtvis löses när du ställer in en sådan konfiguration.
Om automatisk inloggning inte fungerar på ett system, kontrollera om PAM-stacken ”gdm-autologin” är definierad i PAM-konfigurationen. För att detta ska fungera är det nödvändigt att använda en PAM-modul som helt enkelt inte gör någon autentisering, eller som helt enkelt returnerar PAM_SUCCESS från alla dess publika gränssnitt. Under antagandet att ditt system har en pam_allow.so PAM-modul som gör detta, skulle PAM-konfigurationen för att aktivera ”gdm-autologin” se ut så här:
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
Ovanstående inställning kommer att orsaka att ingen lastlog-post genereras. Om en lastlog-post önskas använd följande för sessionen:
gdm-autologin session required pam_unix_session.so.1
Om datorn används av flera människor, vilket gör automatisk inloggning olämplig, kanske du vill låta några användare logga in utan att ange lösenord. Denna funktion kan aktiveras som en konfiguration per användare i verktyget user-admin från gnome-system-tools; det uppnås genom att kontrollera om användaren är medlem i en Unix-grupp kallad ”nopasswdlogin” innan lösenordsfrågan. För att detta ska fungera måste PAM-konfigurationsfilen för ”gdm”-tjänsten inkludera en rad i stil med:
gdm auth sufficient pam_succeed_if.so user ingroup nopasswdlogin
3.3. utmp och wtmp
GDM genererar poster i utmp- och wtmp-användarkontodatabaserna vid sessionsinloggning och -utloggning. utmp-databasen innehåller användartillträde och kontoinformation som används av kommandon så som finger, last, login, och who. wtmp-databasen innehåller historiken för användartillträde och kontoinformation för utmp-databasen. Se även manualsidorna för utmp och wtmp på ditt system för vidare information.
3.4. Xserver-autentiseringssystem
Xserver-autentiseringsfiler sparas i en nyskapad underkatalog i <var>/run/gdm vid uppstart. Dessa filer används för att spara och dela ett ”lösenord” mellan X-klienter och Xservern. Detta ”lösenord” är unikt för varje sessionsinloggning, så användare från en session kan inte snoka i andra användares sessioner.
GDM har bara stöd för MIT-MAGIC-COOKIE-1 Xserver-autentiseringssystemet. Normalt tjänar man väldigt lite på andra system och inga försök har gjort för att implementera dem så här långt. Var speciellt aktsam med att använda XDMCP eftersom Xserverns autentiseringskaka överförs i klartext. Om snokande är möjligt kan en angripare enkelt snoka reda på ditt autentiseringslösenord när du logga in, oavsett vilket autentiseringsystem som används. Om snokande är möjligt och oönskad, bör du använda ssh för att tunnla en X-anslutning snarare än att använda XDMCP. Du kan tänka på XDMCP som en sorts grafiskt telnet, som har samma säkerhetsproblem. I de flesta fall bör ssh -Y föredras framför GDM:s XDMCP-funktioner.
3.5. XDMCP-säkerhet
Även om din display skyddas av kakor kommer XEvent och därför tangentnedslag vid lösenordsinmatning fortfarande överföras i klartext. Det är trivialt att fånga in dessa.
XDMCP är primärt användbart för att köra tunna klienter som exempelvis i terminal-laboratorier. Dessa tunna klienter kommer endast att använda nätverket för att nå servern så det förefaller som den bästa säkerhetspolicyn är att ha de tunna klienterna på ett separat nätverk, som inte kan nås av resten av världen, och de kan bara ansluta till servern. Den enda punkten från vilken du behöver tillgång till utsidan är från servern. Denna typ av installation bör aldrig använda en ohanterad hubb eller annat nätverk som man kan fånga paket från.
3.6. XDMCP tillgångskontroll
XDMCP tillgångskontroll genomförs med hjälp av TCP wrappers. Det är möjligt att kompilera GDM utan stöd för TCP wrapper, så stöd för denna funktion kanske inte finns under vissa operativsystem.
Du bör använda demonnamnet gdm i filerna <etc>/hosts.allow och <etc>/hosts.deny. För att till exempel neka datorer från .evil.domain att logga in, lägg till
gdm: .evil.domain
till <etc>/hosts.deny. Du kan också behöva lägga till
gdm: .din.domän
till din <etc>/hosts.allow om du normalt inte tillåter alla tjänster från alla värdar. Se manualsidan hosts.allow(5) för vidare detaljer.
3.7. Brandväggssäkerhet
Även om GDM försöker att överlista potentiella angripare som försöker dra nytta av XDMCP är det fortfarande rekommenderat att du blockerar XDMCP-porten (normalt UDP-port 177) i din brandvägg om den inte verkligen behövs. GDM skyddar mot överbelastningsattacker men X-protokollet är ändå osäkert till sin natur och bör bara användas i kontrollerade miljöer. Dessutom tar varje fjärranslutning upp massor av resurser så det är mycket enklare att genomföra en överbelastningsattack via XDMCP än att attackera en webbserver.
Det är också vist att blockera alla Xserverns portar. Dessa är TCP-portarna 6000+ (en för varje displaynummer) i din brandvägg. Notera att GDM kommer att använda displaynummer 20 och högre för flexibla on-demand-servrar.
X är inte ett särskilt säkert protokoll om det används över internet och XDMCP är ännu osäkrare.
3.8. PolicyKit
GDM kan konfigureras att använda PolicyKit för att låta systemadministratören kontrollera huruvida inloggningsskärmen bör erbjuda nedstängnings- och omstartsknapparna på inloggningsskärmen.
Dessa knappar kontrolleras av respektive åtgärd org.freedesktop.consolekit.system.stop-multiple-users och org.freedesktop.consolekit.system.restart-multiple-users. Policyer för dessa åtgärder kan ställas in via verktyget polkit-gnome-authorization eller kommandoradsprogrammet polkit-auth.
3.9. RBAC (Roll-baserad tillgångskontroll)
GDM kan konfigureras att använda RBAC istället för PolicyKit. I detta fallet används RBAC-konfigurationen för att kontrollera huruvida inloggningsskärmen ska erbjuda nedstängnings- och omstartsknapparna på inloggningsskärmen.
I Oracle Solaris används till exempel ”solaris.system.shutdown”-tillståndet för att styra detta. Modifiera helt enkelt filen /etc/user_attr så att ”gdm”-användaren har detta tillstånd.