Kapitel 7 Referensinformation för SEAM

Det här kapitlet innehåller information om filer, kommandon och bakgrundsprogram i SEAM. Dessutom innehåller kapitlet ingående information om hur verifieringssystemet Kerberos fungerar.

Här är en lista över referensinformation i kapitlet.

• "filer i SEAM"

• "SEAM-kommandon"

• "Bakgrundsprogram i SEAM"

• "SEAM-terminologi"

• "Så fungerar verifieringssystemet"

• "Skaffa åtkomst till tjänster med SEAM"

• "Använda tabellen gsscred"

filer i SEAM

Konfigurationsfil för PAM

Standardkonfigurationsfilen för PAM som följer med SEAM innehåller poster för hantering av de nya Kerberos-anpassade programmen. Den nya filen innehåller poster för modulerna för verifieringstjänsten, kontohantering, sessionshantering och lösenordshantering.

För verifieringsmodulen finns det nya poster för rlogin, login, dtlogin, krlogin, ktelnet och krsh. Ett exempel på de nya posterna visas nedan. Alla dessa tjänster använder det nya PAM-biblioteket, /usr/lib/security/pam_krb5.so.1, för Kerberos-verifiering.

För de första tre posterna används alternativet try_first_pass, vilket begär verifiering med användarens första lösenord. Det innebär att användaren inte tillfrågas om andra lösenord även om flera mekanismer finns i listan.

För följande tre poster används alternativet acceptor , vilket förhindrar PAM-modulen från att utföra steget för att hämta den första biljettbeviljarbiljetten (TGT). När Kerberos-anpassade program används utförs utbytet av programmet och därför behöver inte steget utföras med PAM. Dessutom finns posten other med som standardpost för alla poster som kräver verifiering som inte har angetts.

# cat /etc/pam.conf
 .
 .
rlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
login auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
dtlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
krlogin auth required /usr/lib/security/pam_krb5.so.1 acceptor
ktelnet auth required /usr/lib/security/pam_krb5.so.1 acceptor
krsh auth required /usr/lib/security/pam_krb5.so.1 acceptor
other auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass

För kontohanteringen har dtlogin en ny post som använder Kerberos-biblioteket, vilket visas nedan. En other-post finns med för en standardregel. För tillfället vidtas inga åtgärder av posten other.

dtlogin account optional /usr/lib/security/pam_krb5.so.1 
other account optional /usr/lib/security/pam_krb5.so.1

De två sista posterna i filen /etc/pam.conf visas nedan. Posten other för sessionshantering förstör användarreferenser. Den nya posten other för lösenordshantering väljer Kerberos-biblioteket.

other session optional /usr/lib/security/pam_krb5.so.1 
other password optional /usr/lib/security/pam_krb5.so.1 try_first_pass

SEAM-kommandon

I det här avsnittet beskrivs några av de kommandon som ingår i SEAM.

Ändringar i kommandot share.

Förutom nya SEAM-kommandon innehåller SEAM ändringar i kommandot share för Solaris 2.6 och Solaris 7. Kommandot share kan användas med tre nya säkerhetslägen:

krb5

Välj Kerberos-verifiering.

krb5i

Välj Kerberos-verifiering med integritetskontroll.

krb5p

Välj Kerberos-verifiering med integritetskontroll (integrity) och skydd av personuppgifter (privacy).

När du använder flera säkerhetslägen med kommandot share, används det första angivna läget som standard om klienten inte anger ett säkerhetsläge. I annat fall används läget som anges av klienten.

Om en monteringsbegäran med ett Kerberos-läge misslyckas, slutförs monteringen med none som säkerhetsläge. Det här inträffar vanligen när root-principalen på NFS-klienten inte är verifierad. Monteringsbegäran kan lyckas, men användaren kommer inte åt filerna såvida de inte är verifierade via Kerberos. Alla transaktioner mellan klienten och servern kräver Kerberos-verifiering, även om filsystemet inte har monterats med ett säkerhetsläge för Kerberos.

Bakgrundsprogram i SEAM

Bakgrundsprogrammen i SEAM visas i följande tabell.

SEAM-terminologi

I följande avsnitt presenteras de termer som används i dokumentationen för SEAM. Det är viktigt att du förstår innebörden av termerna för att kunna ta del av dokumentationen.

Verifieringsspecifik terminologi

Du bör känna till termerna nedan för att kunna förstå verifieringsprocessen. Programmerare och systemadministratörer bör känna till de här termerna.

En klient är programvaran som körs på användarens arbetsstation. SEAM-programvaran som körs på klienten gör eventuella förfrågningar under den här processen och det är viktigt att skilja på åtgärder som utförs av programvaran och åtgärder som utförs av användaren.

Termerna server och tjänst används ofta med samma innebörd. För att klargöra används termen server för att ange vilken dator som SEAM-programvaran körs på. Termen tjänst motsvarar en viss funktionen som stöds på en server (t ex ftp och nfs). I annan dokumentation nämns ofta servrar som delar av tjänster, men en sådan definition gör betydelsen av termerna oklar. I den här dokumentationen refererar servrar till själva datorerna och tjänster till programvara.

SEAM innehåller tre olika nyckeltyper. En av dem är den privata nyckeln. Den här nyckeln ges till varje användarprincipal och är endast känd av principalens användare och av KDC:n. För användarprincipaler baseras nyckeln på användarens lösenord. För servrar och tjänster kallas nyckeln tjänstnyckel. Den här nyckeln fungerar på samma sätt som en privat nyckel, men används av servrar och tjänster. Den tredje nyckeltypen är sessionsnyckeln. Det här är en nyckel som skapas av verifieringstjänsten eller biljettbeviljartjänsten. En sessionsnyckel skapas för säkra transaktioner mellan en klient och en tjänst.

En biljett är ett informationspaket som används för säker överföring av en användares identitet till en server eller tjänst. En biljett gäller bara för en klient och en viss tjänst på en viss server. Biljetten innehåller principalnamnet för tjänsten, principalnamnet för användaren, IP-adressen till användarens värd, en tidsstämpel och ett värde som begränsar biljettens giltighetstid. En biljett skapas med en slumpmässig sessionsnyckel som används av klienten och tjänsten. När en biljett har skapats kan den återanvändas tills den upphör att gälla.

En referens är ett informationspaket som innehåller en biljett och en matchande sessionsnyckel. Referenser krypteras ofta med antingen en privat nyckel eller en tjänstnyckel, beroende på vad som ska användas för dekryptering av referensen.

En verifierare är en annan typ av information. En verifierare kan användas tillsammans med en biljett för att verifiera en användarprincipal. En verifierare innehåller principalnamnet för användaren, IP-adressen till användarens värd och en tidsstämpel. Till skillnad från en biljett går det bara att använda en verifierare en gång, vanligen vid begäran om åtkomst till en tjänst. Verifieraren krypteras med hjälp av sessionsnyckeln för klienten och servern.

Biljettyper

Biljetter har egenskaper som styr hur de kan användas. Egenskaperna tilldelas biljetten när den skapas, men du kan ändra dem senare. (En biljett kan t ex ändras från forwardable (vidarebefordingsbar) till forwarded (vidarebefordrad).) Du kan visa biljettegenskaperna med kommandot klist (se "Så här visar du biljetter").

Det går att beskriva biljetter med en eller flera av följande termer:

forwardable/forwarded (vidarebefordringsbar/vidarebefordrad)

En biljett som är vidarebefordringsbar kan skickas från en värd till en annan, vilket gör att klienten inte behöver verifieras på nytt. Om t ex användaren johan får en vidarebefordringsbar biljett när han befinner sig på evas dator kan han logga in på sin egen dator utan att han behöver hämta en ny biljett (han undviker därmed att behöva verifiera sig på nytt). (Ett exempel på en vidarebefordringsbar biljett finns i "Exempel - Skapa en biljett".) Jämför en vidarebefordringsbar biljett med en biljett med egenskapen proxiable (proxybiljett) nedan.

start

En biljett med egenskapen initial (startbiljett) är en biljett som ges ut direkt och som inte baseras på en biljettbeviljarbiljett. Vissa tjänster, t ex program som ändrar lösenord, kan kräva att biljetter märks med intial (startbiljett) för att kunna försäkra sig själva om att klienten kan visa att den känner till sin hemliga nyckel - eftersom en biljett med egenskapen initial (startbiljett) visar att klienten nyligen har verifierat sig själv (i stället för att vara beroende av en biljettbeviljarbiljett som kan vara gammal).

ogiltigt

En biljett som har egenskapen invalid (ogiltig biljett) är en efterdaterad biljett som ännu inte går att använda. (Se postdated (efterdaterad) nedan.) Biljetten avslås av programservern till dess den är kontrollerad. För att kontrolleras måste den visas för KDC:n av klienten i TGS-förfrågan med flaggan VALIDATE inställd, när dess starttid har passerats.

postdatable/postdated (efterdaterbar/efterdaterad)

En biljett med egenskapen postdated (efterdaterad) är en biljett som inte blir giltig förrän en viss angiven tid efter det att den skapades. En sådan biljett är t ex användbar för satsvisa jobb som ska köras sent på kvällen, eftersom biljetten, om den stjäls, inte kan användas förrän jobbet ska köras. När en biljett med egenskapen postdated (efterdaterad) utfärdas, utfärdas den som invalid (ogiltig) och förblir det tills des starttid är passerad och klienten begär kontroll av KDC:n. (Se invalid (ogiltig) ovan.) En biljett med egenskapen postdated (efterdaterad) gäller vanligen tills sista användningstid för biljettbeviljarbiljetten, men om den är märkt renewable (förnyelsebar) anges vanligen dess giltighetstid till att vara densamma som giltighetstiden hos biljettbeviljarbiljetten. Se renewable (förnyelsebar) nedan.

proxybiljett

Ibland kan det vara nödvändigt för en principal att tillåta en tjänst att utföra en åtgärd åt sig själv. (Ett exempel är när en principal begär att en tjänst kör en utskrift på en ytterligare en värd.) Tjänsten måste kunna använda klientens identitet, men bara för en enda åtgärd. Om så är fallet sägs servern fungera som proxy för klienten. Principalnamnet för proxyn måste anges när biljetten skapas.

En biljett med egenskapen proxiable (proxybiljett) liknar en biljett med egenskapen forwardable (vidarebefordringsbar) förutom att den endast gäller en enda tjänst, medan en biljett med egenskapen forwardable (vidarebefordringsbar) gör att tjänsten helt kan använda klientens identitet. En biljett med egenskapen forwardable (vidarebefordringsbar) kan därför ses som en sorts superproxy.

förnyelsebar

Eftersom biljetter med mycket lång giltighetstid innebär en säkerhetsrisk kan biljetter anges som renewable (förnyelsebara). En biljett med egenskapen renewable (förnyelsebar) har två sista användningstider: tiden när den aktuella förekomsten av biljetten går ut och maximal giltighetstid för all biljetter. Om klienten vill fortsätta använda en biljett förnyas biljetten innan första tidsgränsen nås. En biljett kan t ex vara giltig i en timme och alla biljetter ha en maximal giltighetstid på tio timmar. Om klienten som har biljetten vill behålla den i mer än en timme måste klienten förnya biljetten inom en timme. När en biljett når den maximala giltighetstiden för biljetter (tio timmar) slutar den automatiskt att gälla och den kan inte förnyas.

Mer information om hur du visar biljetter och deras attribut finns i linkend="user-1">.

Giltighetstid för biljetter

Varje gång en principal hämtar en biljett, bl a biljettbeviljarbiljetter, ställs biljettens giltighetstid in som det minsta av följande värden:

• Värdet för giltighetstiden som anges av alternativet -l för kinit, om kinit används för att hämta biljetten.

• Värdet för maximal giltighetstid (max_life) som anges i filen kdc.conf.

• Värdet för maximal giltighetstid som anges i Kerberos-databasen för tjänstprincipalen som tillhandahåller biljetten. (För kinit är tjänstprincipalen krbtgt/användarkategori)

• Värdet för maximal giltighetstid som anges i Kerberos-databasen för användarprincipalen som efterfrågar biljetten.

Figur 7-1 visar hur giltighetstiden för en TGT bestäms och åskådliggör var de fyra värdena för giltighetstid kommer från. Även om Figur 7-1 visar hur giltighetstiden för en TGT bestäms händer i stort sett samma sak när alla principaler hämtar en biljett. De enda skillnaderna är att kinit inte tillhandahåller ett värde för giltighetstid och att tjänstprincipalen som tillhandahåller biljetten tillhandahåller ett värde för maximal giltighetstid (i stället för principalen krbtgt/användarkategori.)

Figur 7-1 Så avgörs giltighetstiden för en TGT

Giltighetstiden för en förnyelsebar biljett avgörs också av det minsta av fyra värden, men i stället används förnyelsebara tider för giltighetstid:

• Värdet för den förnyelsebara giltighetstiden som anges av alternativet -r för kinit, om kinit används för att hämta eller förnya biljetten.

• Värdet för maximal förnyelsebar giltighetstid (max_renewable_life) som anges i filen kdc.conf.

• Värdet för maximal förenyelsebar giltighetstid som anges i Kerberos-databasen för tjänstprincipalen som tillhandahåller biljetten (för kinit är tjänstprincipalen krbtgt/användarkategori).

• Värdet för maximal förnyelsebar giltighetstid som anges i Kerberos-databasen för användarprincipalen som efterfrågar biljetten.

Principalnamn

Alla biljetter identifieras med ett principalnamn. Principalnamnet kan identifiera en användare eller tjänst. Här följer exempel på flera principalnamn.

Så fungerar verifieringssystemet

Programmen tillåter att du loggar in på ett fjärrsystem om du kan visa en biljett som bevisar din identitet och en matchande sessionsnyckel. Sessionsnyckeln innehåller information som gäller användaren och tjänsten som används. En biljett och en sessionsnyckel skapas av KDC:n för alla användare när de loggar in för första gången. Tillsammans utgör biljetten och den matchande sessionsnyckeln en referens. En användare som använder flera nätverkstjänster kan samla på sig många referenser. Användaren behöver en referens för varje tjänst som körs på en viss server. Till exempel krävs en referens för åtkomst till tjänsten ftp på en server med namnet boston, och för åtkomst till tjänsten ftp på en annan server krävs en annan referens.

Processen för att att skapa och lagra referenser är klar och tydlig. Referenser skapas av KDC:n som skickar referensen till den som ställer begäran. När den tas emot lagras referensen i en referenscache.

Skaffa åtkomst till tjänster med SEAM

För att en användare ska kunna få åtkomst till en viss tjänst på en viss server måste användaren skaffa två saker. Den första är en referens för biljettbeviljartjänsten (kallas för TGT). När biljettbeviljartjänsten har dekrypterat den här referensen skapar tjänsten en andra referens för servern som användaren begär åtkomst till. Den här andra referensen kan sedan användas för att begära åtkomst till tjänsten på servern. När servern har dekrypterat den andra referensen får användaren åtkomst till tjänsten. Den här processen beskrivs mer ingående nedan.

Skaffa en referens för biljettbeviljartjänsten

1. När verifieringsprocessen ska startas skickar klienten en förfrågan till verifieringsservern för en viss användarprincipal. Den här förfrågan skickas utan kryptering. Det finns ingen känslig information i förfrågan så kryptering är överflödig.

2. När förfrågan tas emot av verifieringstjänsten slås principalnamnet för användaren upp i KDC-databasen. Om det finns en matchande principal hämtar verifieringstjänsten principalens privata nyckel. Verifieringstjänsten skapar sedan en sessionsnyckel som ska användas av klienten och biljettbeviljartjänsten (sessionsnyckel 1) och en biljett för biljettbeviljartjänsten (biljett 1). Den här biljetten kallas även biljettbeviljarbiljetten eller TGT. Både sessionsnyckeln och biljetten krypteras med användarens privata nyckel och informationen skickas sedan tillbaka till klienten.

3. Klienten använder informationen för att dekryptera sessionsnyckel 1 och biljett 1 med hjälp av den privata nyckeln för användarprincipalen. Eftersom den privata nyckeln endast ska kännas till av användaren och KDC-databasen, bör information i paketet vara säker. Klienten lagrar informationen i referenscachen.

Under processen tillfrågas vanligen användaren om ett lösenord. Om lösenordet som användaren anger är detsamma som det som användes för att skapa den privata nyckeln som lagras i KDC-databasen, kan klienten dekryptera informationen som skickas av verifieringstjänsten. Nu har klienten en referens som kan användas med biljettbeviljartjänsten. Klienten är klar att begära en referens för en server.

Figur 7-2 Hämta en referens för biljettbeviljartjänsten

Hämta en referens för en server

1. För att kunna begära åtkomst till en viss server måste klienten först ha hämtat en referens för servern från verifieringstjänsten (se "Skaffa en referens för biljettbeviljartjänsten"). Klienten skickar sedan en förfrågan till biljettbeviljartjänsten med tjänstens principalnamn, biljett 1 och en verifierare krypterad med sessionsnyckel 1. Biljett 1 krypterades ursprungligen av verifieringstjänsten med hjälp av tjänstnyckeln för biljettbeviljartjänsten.

2. Biljetten kan dekrypteras eftersom biljettbeviljartjänsten känner till sin egen tjänstnyckel. Biljettbeviljartjänsten kan dekryptera verifieraren eftersom sessionsnyckel 1 ingår i informationen i biljett 1. Nu har användarprincipalen verifierats med biljettbeviljartjänsten.

3. När verifieringen är genomförd skapar biljettbeviljartjänsten en sessionsnyckel för användarprincipalen och servern (sessionsnyckel 2) och en biljett för servern (biljett 2). Sessionsnyckel 2 och biljett 2 krypteras sedan med sessionsnyckel 1. Eftersom sessionsnyckel 1 endast är känd för klienten och biljettbeviljartjänsten, är informationen säker och kan skickas över nätverket utan risk.

4. När klienten tar emot informationspaketet dekrypteras informationen med sessionsnyckel 1, som lagras i referenscachen. Klienten har hämtat en referens som ska användas med servern. Nu är klienten klar för att begära åtkomst till en viss tjänst på servern.

Figur 7-3 Hämta en referens för en server

Skaffa åtkomst till en viss tjänst

1. För att kunna begära åtkomst till en viss tjänst måste klienten först ha skaffat en referens för biljettbeviljartjänsten från verifieringsservern och en serverreferens från biljettbeviljartjänsten (se "Skaffa en referens för biljettbeviljartjänsten" och "Hämta en referens för en server"). Klienten kan skicka en begäran till servern som innehåller biljett 2 och en annan verifierare. Verifieraren krypteras med sessionsnyckel 2.

2. Biljett 2 krypterades av biljettbeviljartjänsten med tjänstnyckeln för tjänsten. Eftersom tjänstnyckeln är känd för tjänstprincipalen kan tjänsten dekryptera nyckel 2 och hämta sessionsnyckel 2. Sessionsnyckel 2 kan sedan användas för att dekryptera verifieraren. När verifieraren har dekrypterats får klienten åtkomst till tjänsten.

Figur 7-4 Skaffa åtkomst till en viss tjänst

Använda tabellen gsscred

Tabellen gsscred används av en NFS-server när servern försöker identifiera en SEAM-användare. NFS-tjänsterna använder UNIX-ID:n för att identifiera användare - dessa ID:n ingår inte i användarprincipaler eller referenser. Tabellen gsscred innehåller avbildningar från UNIX-ID:n (från lösenordsfilen) till principalnamn. Tabellen måste skapas och administreras efter att KDC-databasen har fyllts.

När en klientförfrågan ställs försöker NFS-tjänsterna att avbilda principalnamnet till ett UNIX-ID. Om avbildningen inte fungerar kontrollerar tjänsterna tabellen gsscred. Med mekanismen kerberos_v5 avbildas en root/värdnamn-principal automatiskt till UID 0 (Användar-ID 0) och tabellen gsscred kontrolleras inte. Det innebär att det inte finns något sätt att utföra särskilda omavbildningar av root via tabellen gsscred.

Val av mekanism för tabellen gsscred

Vilken mekanism som ska väljas för tabellen gsscred beror på en rad faktorer.

• Vill du minska tiden det tar att slå upp poster?

• Vill du öka säkerheten för dataåtkomst?

• Vill du att filen skapas snabbt?

Här följer en lista med beskrivningar av alla stödmekanismer som kan väljas.

filer

Tabellen gsscred lagras i ett filsystem. Ett icke delat lokalt filsystem ger det säkraste stödet, eftersom det inte görs några överföringar via nätverket när tabellen har skapats. Den här versionen av filen går snabbast att skapa.

xfn_files

Tabellen gsscred lagras i filsystemet /var/fn. Det här filsystemet kan vara delat eller icke delat. Det tar lång tid att skapa xfn-filer.

xfn_nis

Tabellen gsscred lagras i NIS-namnutrymmet. Undersökningar i det här filsystemet är inte säkra. Det tar lång tid att skapa xfn-filer.

xfn_nisplus

Tabellen gsscred lagras i NIS+-namnutrymmet. Undersökningar i det här filsystemet är inte säkra. Det tar lång tid att skapa xfn-filer.

xfn

Tabellen gsscred lagras i standardsystemet för xfn. Det tar lång tid att skapa xfn-filer.

Den första undersökningen kan vara långsam för stödmekanismen för stödmekanismen för filer. För de andra mekanismerna kan det första undersökningen vara snabbare om en namntjänst används. När informationen är lagrad i cacheminnet bör hämtningstiden vara densamma för alla mekanismer.