Capitolo 7 Informazioni di riferimento su SEAM

In questo capitolo sono descritti vari file, comandi e daemon che fanno parte di SEAM. Inoltre, il capitolo contiene informazioni dettagliate sul funzionamento del sistema di autenticazione Kerberos.

Qui di seguito sono elencati i tipi di informazioni di riferimento contenuti in questo capitolo.

• "File di SEAM"

• "Comandi di SEAM"

• "Daemon di SEAM"

• "Terminologia di SEAM"

• "Funzionamento del sistema di autenticazione"

• "Accesso a un servizio con SEAM"

• "Uso della tabella gsscred"

File di SEAM

File di configurazione PAM

Il file di configurazione PAM predefinito di SEAM include una serie di istruzioni per la gestione delle nuove applicazioni basate su Kerberos. Il nuovo file include istruzioni per il servizio di autenticazione, la gestione degli account, la gestione delle sessioni e la gestione delle password.

In relazione al modulo di autenticazione, le nuove istruzioni riguardano rlogin, login, dtlogin, krlogin, ktelnet e krsh. Qui sotto è mostrato un esempio di queste istruzioni. Tutti questi servizi utilizzano la nuova libreria PAM, /usr/lib/security/pam_krb5.so.1, per l'autenticazione Kerberos.

Le prime tre righe utilizzano l'opzione try_first_pass, che richiede l'autenticazione mediante la password iniziale dell'utente. L'uso della password iniziale comporta che all'utente non venga richiesta un'altra password, anche se sono elencati più meccanismi.

Le tre righe successive utilizzano l'opzione acceptor per evitare che il modulo PAM esegua la procedura per ottenere il TGT iniziale. Le applicazioni server basate su Kerberos eseguono lo scambio direttamente, perciò non è necessario che la procedura venga svolta con il modulo PAM. Inoltre, è inclusa un'istruzione con una voce other predefinita da utilizzare per tutte le operazioni non specificate che richiedono un'autenticazione.

# 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

In relazione alla gestione degli account, dtlogin ha una nuova riga che utilizza la libreria Kerberos, come mostrato qui sotto. È anche inclusa una voce other per l'uso di una regola predefinita. Attualmente non vi è nessuna azione che viene eseguita con la voce other.

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

Qui sotto sono mostrate le ultime due righe del file /etc/pam.conf. La voce other per la gestione delle sessioni distrugge le credenziali dell'utente. La nuova voce other per la gestione delle password seleziona la libreria Kerberos.

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

Comandi di SEAM

In questa sezione sono elencati alcuni dei comandi inclusi in SEAM.

Modifiche al comando share

Oltre ai nuovi comandi di SEAM, il prodotto SEAM include alcune modifiche al comando share fornito con le release Solaris 2.6 e Solaris 7. Il comando share può usare tre nuove modalità di sicurezza:

krb5

Seleziona l'autenticazione Kerberos

krb5i

Seleziona l'autenticazione Kerberos con la funzione di integrità

krb5p

Seleziona l'autenticazione Kerberos con le funzioni di integrità e riservatezza

Quando il comando share include più modalità, quella elencata per prima viene utilizzata come modalità predefinita se il client non specifica alcuna modalità di sicurezza. Diversamente, viene utilizzata la modalità selezionata dal client.

Se una richiesta di attivazione che utilizza una modalità Kerberos non riesce, l'attivazione viene completata con la modalità di sicurezza none. Spesso, questo si verifica quando il nome principale root sul client NFS non è autenticato. La richiesta di attivazione può riuscire, ma l'utente non potrà accedere ai file a meno che essi non vengano autenticati con Kerberos. Tutte le transazioni tra il client e il server richiedono l'autenticazione Kerberos, anche se il file system non viene attivato con una modalità di sicurezza Kerberos.

Daemon di SEAM

La tabella seguente elenca i daemon utilizzati dal prodotto SEAM.

Terminologia di SEAM

La sezione seguente presenta i termini utilizzati nella documentazione di SEAM con le relative definizioni. La comprensione di questi termini è essenziale per poter seguire correttamente le istruzioni fornite nei manuali.

Terminologia riguardante l'autenticazione

I termini descritti in questa sezione sono necessari per la comprensione del processo di autenticazione, in particolare per i programmatori e gli amministratori di sistema.

Il termine client indica il software eseguito sulla workstation dell'utente. Il software SEAM eseguito sul client effettua molte richieste durante questo processo, ed è importante distinguere le azioni di questo software da quelle dell'utente.

I termini server e servizio sono spesso utilizzati in modo intercambiabile. Per maggiore chiarezza, il termine server viene usato per designare il sistema fisico su cui viene eseguito il software SEAM. Il termine servizio corrisponde a una funzione particolare supportata su un server (ad esempio, ftp o nfs). Nella documentazione, i server sono spesso citati come parte di un servizio, ma l'uso di questa definizione può confondere il significato dei termini; in generale, il termine server si riferisce al sistema fisico e il termine servizio si riferisce al software.

Il prodotto SEAM include tre tipi di chiavi. Una di queste è la chiave privata. Questa chiave viene fornita a tutti i nomi principali di utenti ed è nota solo all'utente di quel nome principale e al KDC. Per i nomi principali degli utenti, la chiave è basata sulla password dell'utente. Per server e servizi, la chiave viene detta chiave di servizio. Questa chiave ha la stessa funzione della chiave privata, ma viene usata da server e servizi. Il terzo tipo di chiave è la chiave di sessione. Questa chiave viene generata dal servizio di autenticazione o dal TGT e ha lo scopo di consentire transazioni sicure tra un client e un servizio.

Un ticket è un pacchetto di informazioni usato per trasmettere in modo sicuro l'identità di un utente a un server o a un servizio. Un ticket è valido solo per un certo client e un determinato servizio su un server specifico. Esso contiene il nome principale del servizio, il nome principale dell'utente, l'indirizzo IP dell'host dell'utente, un'indicazione di data e ora e un valore che definisce la durata del ticket. Il ticket viene creato con una chiave di sessione casuale che deve essere utilizzata dal client e dal servizio. Il ticket, una volta creato, può essere usato fino alla scadenza.

Una credenziale è un pacchetto di informazioni che include un ticket e una chiave di sessione corrispondente. Le credenziali vengono spesso cifrate mediante una chiave privata o una chiave di servizio, a seconda di come dovranno essere decifrate.

I dati di autenticazione sono un altro tipo di informazioni. Se usati con un ticket, i dati di autenticazione possono servire per autenticare il nome principale di un utente. I dati di autenticazione includono il nome principale dell'utente, l'indirizzo IP dell'host dell'utente e un'indicazione di data e ora. A differenza dei ticket, i dati di autenticazione possono essere usati una sola volta, solitamente quando viene richiesto l'accesso a un servizio. I dati di autenticazione vengono cifrati usando la chiave di sessione specifica del client e del server.

Tipi di ticket

I ticket sono dotati di proprietà che determinano in che modo possono essere utilizzati. Queste proprietà vengono assegnate durante la loro creazione, ma possono essere modificate successivamente. (Ad esempio, un ticket inoltrabile può diventare inoltrato.) Le proprietà dei ticket possono essere visualizzate con il comando klist (vedere "Visualizzare i ticket").

I ticket possono essere definiti da uno o più dei seguenti termini:

inoltrabile/inoltrato

Un ticket inoltrabile può essere inviato da un host ad un altro, evitando al client di doversi autenticare nuovamente. Ad esempio, se l'utente davide ottiene un ticket inoltrabile mentre lavora sul sistema di giovanna, egli potrà eseguire il login sul proprio sistema senza bisogno di richiedere un nuovo ticket (e perciò senza doversi autenticare nuovamente). (Per un esempio di ticket inoltrabile, vedere "Esempio: Creazione di un ticket".) Confrontare il ticket inoltrabile con il ticket delegabile descritto più avanti.

iniziale

Un ticket si dice iniziale quando viene emesso direttamente, cioè non sulla base di un TGT. Alcuni servizi, come le applicazioni per la modifica delle password, richiedono che i ticket siano iniziali per avere la certezza che il client conosca la sua chiave segreta. Un ticket iniziale indica infatti che il client si è autenticato recentemente (invece di operare sulla base di un TGT, che può essere stato emesso da diverso tempo).

non valido

Si dice non valido un ticket postdatato che non sia ancora diventato utilizzabile. (Vedere la definizione di postdatato.) Questi ticket vengono rifiutati dai server di applicazioni finché non diventano validi. Per diventare validi, essi devono essere presentati al KDC dal client in una richiesta TGS, con il flag VALIDATE, una volta trascorsa la data iniziale.

postdatabile/postdatato

Un ticket si dice postdatato quando diventa valido dopo un certo tempo dalla sua creazione. Questi ticket sono utili, ad esempio, per i lavori batch da eseguire durante la notte, poiché in caso di furto non potranno essere utilizzati fino all'ora stabilita per l'esecuzione del lavoro. I ticket postdatati vengono generati come non validi e rimangono tali fino a quando non trascorre la loro data iniziale e finché il client non richiede una convalida al KDC. (Vedere la definizione di non valido.) I ticket postdatati sono normalmente validi fino alla data di scadenza del TGT; tuttavia, se sono rinnovabili, la loro durata è normalmente uguale all'intera durata del TGT. Vedere la definizione di rinnovabile.

delegabile/proxy

A volte, si può avere la necessità che un servizio esegua un'operazione per conto di un nome principale. (Ad esempio, un nome principale può richiedere a un servizio di eseguire un lavoro di stampa su un terzo host.) Il servizio deve avere la possibilità di assumere l'identità del client, ma per una sola operazione. In questo caso, si dice che il server funge da proxy per il client. Il nome principale del proxy deve essere specificato durante la creazione del ticket.

Un ticket delegabile è simile a un ticket inoltrabile, ma è valido solo per un singolo servizio, mentre i ticket inoltrabili concedono al servizio l'uso completo dell'identità del client. Un ticket inoltrabile può perciò essere considerato una sorta di super-proxy.

rinnovabile

Poiché i ticket con una durata molto lunga possono rappresentare un rischio per la sicurezza, i ticket possono essere designati come rinnovabili. Un ticket rinnovabile ha due date di scadenza: la data di scadenza dell'istanza corrente del ticket e la durata massima applicata a tutti i ticket. Se un client vuole continuare ad usare un certo ticket, esso può rinnovarlo prima della prima data di scadenza. Ad esempio, si supponga che un ticket abbia una validità di un'ora e che la durata massima di tutti i ticket sia di dieci ore. Se il client in possesso del ticket volesse prolungare la sua durata per più di un'ora, esso dovrà rinnovarlo entro l'ora di validità. Quando un ticket raggiunge la durata massima (10 ore), esso scade automaticamente e non può essere rinnovato.

Per informazioni su come visualizzare gli attributi dei ticket, vedere "Visualizzare i ticket".

Durata dei ticket

Ogni volta che un nome principale ottiene un ticket, inclusi i TGT, la durata del ticket viene impostata in base al valore più piccolo tra i seguenti:

• La durata specificata dall'opzione -l di kinit, se si è usato kinit per ottenere il ticket

• La durata massima (max_life) specificata nel file kdc.conf

• La durata massima specificata nel database di Kerberos per il nome principale del servizio che ha emesso il ticket. (Nel caso di kinit, il nome principale del servizio è krbtgt/settore)

• La durata massima specificata nel database di Kerberos per il nome principale dell'utente che ha richiesto il ticket.

La Figura 7-1 illustra come viene determinata la durata dei TGT e da dove provengono i quattro valori di durata considerati. La Figura 7-1 si riferisce al modo in cui viene determinata la durata di un TGT, ma lo stesso accade essenzialmente ogni volta che un qualunque nome principale ottiene un ticket. Le uniche differenze consistono nel fatto che kinit non fornisce un valore di durata, e che il nome principale del servizio che emette il ticket fornisce un valore per la durata massima (invece del nome principale krbtgt/settore).

Figura 7-1 Come viene determinata la durata di un TGT

La durata dei ticket rinnovabili viene determinata in base al più piccolo di questi quattro valori:

• Il valore della durata rinnovabile specificata dall'opzione -r di kinit, se per ottenere o rinnovare il ticket si è utilizzato kinit

• Il valore della durata massima rinnovabile (max_renewable_life) specificato nel file kdc.conf

• Il valore della durata massima rinnovabile specificato nel database di Kerberos per il nome principale del servizio che ha emesso il ticket (nel caso di kinit, il nome principale del servizio è krbtgt/settore)

• Il valore della durata massima rinnovabile specificato nel database di Kerberos per il nome principale dell'utente che ha richiesto il ticket

Nomi principali

Ogni ticket è identificato da un nome principale. Il nome principale può identificare un utente o un servizio. Qui di seguito sono mostrati alcuni esempi di diversi nomi principali.

Funzionamento del sistema di autenticazione

Le applicazioni permettono di eseguire il login in un sistema remoto se l'utente può esibire un ticket che dimostri la sua identità e una chiave di sessione corrispondente. La chiave di sessione contiene informazioni specifiche sull'utente e sul servizio a cui è richiesto l'accesso. Il ticket e la chiave di sessione vengono creati dal KDC per tutti gli utenti al loro primo login. Il ticket e la chiave di sessione corrispondente formano una credenziale. Quando un utente utilizza più servizi di rete, egli acquisisce diverse credenziali, una per ogni servizio eseguito su un determinato server. Ad esempio, l'accesso al servizio ftp su un server di nome torino richiede una credenziale, e l'accesso al servizio ftp su un altro server richiede una propria credenziale.

Il processo di creazione e memorizzazione delle credenziali è trasparente. Le credenziali vengono create dal KDC che le invia al richiedente. Una volta ricevute, le credenziali vengono memorizzate in un'apposita cache.

Accesso a un servizio con SEAM

Per poter accedere a un determinato servizio su un determinato server, l'utente deve ottenere due cose. La prima è la credenziale per il TGT. Quando il servizio che deve emettere il ticket (TGS) decifra la credenziale, esso crea una seconda credenziale per il server a cui l'utente ha richiesto l'accesso. Questa seconda credenziale può quindi essere usata per richiedere l'accesso al servizio sul server. Se il server decifra correttamente la seconda credenziale, esso concede l'accesso all'utente. Questo processo è descritto in maggiore dettaglio qui di seguito.

Acquisizione di una credenziale per un TGS

1. Per iniziare il processo di autenticazione, il client invia una richiesta al server di autenticazione per un nome principale di un utente. Questa richiesta viene inviata non cifrata, poiché non contiene informazioni che richiedono protezione.

2. Quando il servizio di autenticazione riceve la richiesta, esso ricerca il nome principale dell'utente nel database del KDC e, se lo trova, ottiene la chiave privata per quel nome principale. Il servizio di autenticazione genera quindi una chiave di sessione che verrà usata dal client e dal servizio che ha emesso il ticket (TGS) (chiave di sessione 1) e un ticket per il TGS (ticket 1). Questo ticket è detto TGT. Sia la chiave di sessione che il ticket vengono cifrati usando la chiave privata dell'utente e le informazioni vengono rinviate al client.

3. Il client utilizza queste informazioni per decifrare la chiave di sessione 1 e il ticket 1 usando la chiave privata per il nome principale dell'utente. Poiché la chiave privata dovrebbe essere nota solo all'utente e al database del KDC, le informazioni contenute nel pacchetto dovrebbero essere sicure. Il client memorizza le informazioni nella cache delle credenziali.

Normalmente, durante questa procedura il sistema richiede all'utente di inserire la sua password. Se la password inserita è uguale a quella utilizzata per la creazione della chiave privata memorizzata nel database del KDC, il client può decifrare correttamente le informazioni inviate dal servizio di autenticazione. A questo punto il client dispone di una credenziale da usare con il TGS ed è pronto per richiedere una credenziale per un server.

Figura 7-2 Acquisizione di una credenziale per il TGS

Acquisizione di una credenziale per un server

1. Per richiedere l'accesso a un server specifico, un client deve prima aver ottenuto una credenziale per quel server dal servizio di autenticazione (vedere "Acquisizione di una credenziale per un TGS"). Il client invia quindi al TGS una richiesta che include il nome principale del servizio, il ticket 1 e i dati di autenticazione cifrati con la chiave di sessione 1. Il ticket 1 era stato originariamente cifrato dal servizio di autenticazione usando la chiave di servizio del TGS.

2. Poiché il TGS conosce la sua chiave di servizio, esso può decifrare il ticket 1. Le informazioni incluse nel ticket 1 includono la chiave di sessione 1, per permettere al TGS di decifrare i dati di autenticazione. A questo punto, il nome principale dell'utente viene autenticato presso il TGS.

3. Una volta effettuata l'autenticazione, il TGS genera una chiave di sessione per il nome principale dell'utente e per il server (chiave di sessione 2) e un ticket per il server (ticket 2). La chiave di sessione 2 e il ticket 2 vengono quindi cifrati usando la chiave di sessione 1. Poiché la chiave di sessione 1 è nota solo al client e al TGS, queste informazioni sono sicure e possono essere trasmesse con sicurezza attraverso la rete.

4. Quando il client riceve questo pacchetto di informazioni, esso lo decifra usando la chiave di sessione 1, che aveva memorizzato nella cache delle credenziali. Il client ha così ottenuto una credenziale da utilizzare con il server, ed è pronto per richiedere l'accesso a un determinato servizio su quel server.

Figura 7-3 Acquisizione di una credenziale per un server

Accesso a un server specifico

1. Per richiedere l'accesso a un servizio specifico, il client deve prima ottenere una credenziale per il TGS dal server di autenticazione, e una credenziale per il server dal TGS (vedere "Acquisizione di una credenziale per un TGS" e "Acquisizione di una credenziale per un server"). Il client può inviare una richiesta al server includendovi il ticket 2 e altri dati di autenticazione. I dati di autenticazione vengono cifrati usando la chiave di sessione 2.

2. Il ticket 2 era stato cifrato dal TGS con la chiave di servizio associata al servizio richiesto. Poiché la chiave di servizio è nota al nome principale del servizio, il servizio può decifrare il ticket 2 e acquisire la chiave di sessione 2. La chiave di sessione 2 può quindi essere usata per decifrare i dati di autenticazione. Se i dati di autenticazione vengono decifrati correttamente, il client ottiene l'accesso al servizio.

Figura 7-4 Accesso a un servizio specifico

Uso della tabella gsscred

La tabella gsscred viene usata dai server NFS per identificare gli utenti SEAM. Il servizio NFS utilizza gli ID UNIX per identificare gli utenti, e questi ID non fanno parte del nome principale o delle credenziali degli utenti. La tabella gsscred contiene una mappa che associa agli ID UNIX (ricavati dal file delle password) i relativi nomi principali. La tabella deve essere creata e amministrata dopo aver popolato il database del KDC.

Quando un client invia una richiesta, i servizi NFS cercano di associare al nome principale l'ID UNIX corrispondente. Se questa associazione non riesce, viene consultata la tabella gsscred. Con il meccanismo kerberos_v5, il nome principale root/hostname viene associato automaticamente all'UID 0, e la tabella gsscred non viene consultata. Questo significa che non è possibile rimappare l'identità di root mediante la tabella gsscred.

Meccanismo da selezionare per la tabella gsscred

La scelta del meccanismo corretto per la tabella gsscred dipende da diversi fattori.

• Si vuole migliorare la velocità delle ricerche?

• Si vuole migliorare la sicurezza dell'accesso ai dati?

• Si vuole poter creare il file velocemente?

Qui di seguito sono elencati i meccanismi di base che possono essere selezionati, con una descrizione dei relativi vantaggi.

files

La tabella gsscred viene memorizzata in un file system. Un file system locale non condiviso rappresenta il meccanismo più sicuro, poiché dopo la creazione della tabella non viene fatta alcuna trasmissione attraverso la rete. Questa versione del file è quella che viene creata più velocemente.

xfn_files

La tabella gsscred viene memorizzata nel file system /var/fn. Questo file system può essere o non essere condiviso. Tutti i file xfn richiedono molto tempo per la creazione.

xfn_nis

La tabella gsscred viene memorizzata nello spazio di denominazione NIS. Le ricerche all'interno di questo file system non sono sicure. Tutti i file xfn richiedono molto tempo per la creazione.

xfn_nisplus

La tabella gsscred viene memorizzata nello spazio di denominazione NIS+. Le ricerche all'interno di questo file system non sono sicure. Tutti i file xfn richiedono molto tempo per la creazione.

xfn

La tabella gsscred viene memorizzata nel file system predefinito per xfn. Tutti i file xfn richiedono molto tempo per la creazione.

Con il meccanismo files, la ricerca iniziale può essere lenta. Con gli altri meccanismi, la ricerca iniziale può essere più veloce usando un servizio di denominazione. Con tutti i meccanismi, dopo la memorizzazione dei dati nella cache il tempo di richiamo è pressoché uguale.