Esperienza su PAM
Esperienza su PAM |
|
|
|
Per la realizzazione di questo modulo useremo
Netkit4TIC
con la
connettività
con la rete reale (leggere il file README).
L'ambiente virtuale mette a disposizione un intera macchina dove sono già installati una gran parte dei moduli pam configurabili con i diritti di amministratore. Inoltre, data la connettività con la macchina reale, si possono testare le configurazioni da una shell della macchina reale e, aggiungendo delle regole di routing, anche dalle macchine della rete reale.
Il file con l'esperienza
PAM deve essere
decompresso su una sottodirectory della HOME. In
seguito, dopo aver seguito le istruzioni presenti nel file
README occorre lanciare lo script:
user@realHost$ ./lab start
che ci costruisce un host virtuale con IP address 192.168.77.2 e
con il servizio ssh attivato. Inoltre sono lanciati due
comandi tail su file di log rispettivamente
/var/log/messages e /var/log/auth.log
dove il sistema di logging registra gli eventi più
importanti.
I moduli attualmente installati e quindi configurabili sono:
root@vHost# ls -c /lib/security/ pam_access.so pam_lastlog.so pam_permit.so pam_tmpdir.so pam_cracklib.so pam_ldap.so pam_rhosts_auth.so pam_unix.so pam_debug.so pam_limits.so pam_rootok.so pam_unix_acct.so pam_deny.so pam_listfile.so pam_securetty.so pam_unix_auth.so pam_env.so pam_mail.so pam_shells.so pam_unix_passwd.so pam_filter.so pam_mkhomedir.so pam_smb_auth.so pam_unix_session.so pam_ftp.so pam_motd.so pam_smbpass.so pam_userdb.so pam_group.so pam_mysql.so pam_stress.so pam_warn.so pam_issue.so pam_nologin.so pam_tally.so pam_wheel.so pam_krb5.so pam_opie.so pam_time.so pam_winbind.so
A partire da questa situazione possiamo provare alcuni esempi:
Configurazione del DISPLAY X |
|
In questo modulo utilizzeremo la capacità delle applicazioni
che utilizzano X di essere visualizzate su qualsiasi server X remoto
che ne autorizzi l'uso. A questo scopo il server X remoto deve per
prima cosa essere configurato per accettare connessioni remote (alcuni
le disabilitano per questioni legate alla sicurezza) e in seconda
deve essere settato per accettare connessioni da un particolare nodo.
Noi assumeremo che la prima condizione sia soddisfatta mentre per la
seconda utilizzermo il comando xhost. Assumendo che
la macchina virtuale abbia indirizzo 192.168.77.2 il comando sul
nodo sui cui gira il server X che vuole abilitare le visualizzazioni
della vm sul suo desktop è:
user@realHost$ xhost +192.168.77.2
Ora dobbiamo configurare le applicazioni del nodo virtuale per la visualizzazione nel display remoto (che assumiamo essere 192.168.77.1):
vHost# export DISPLAY=192.168.77.1:0.0
e il gioco è fatto. Possiamo verificarlo con il lancio di
un xterm. Le due finestre di logging che si aprono
al momento dello startup dello script usano questo meccanismo.
Modulo pam_env: set/unset environment variables |
|
Vogliamo cogliere la configurazione descritta nel precedente paragrafo
per mostrare il funzionamento del
modulo pam_env. Supponiamo appunto di voler valorizzare
alcune variabili d'ambiente al login/ssh di un utente. Questo è
possibile configurando i relativi file di login e ssh
presenti nella directory /etc/pam.d:
# /etc/pam.d/login auth required pam_env.so [...]
# /etc/pam.d/ssh auth required pam_env.so [...]
Il modulo è di tipo auth e prevede che la valorizzazione
delle variabili dell'ambiente sia fatta nel file /etc/environment
o nel file /etc/security/pam_env.conf.
Abbiamo deciso per il secondo:
# /etc/security/pam_env.conf
REMOTEHOST DEFAULT=192.168.77.1 OVERRIDE=@{PAM_RHOST}
DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
In questo modo al prossimo login:
user@realHost$ ssh root@192.168.77.2 Password: root root@vHost# echo $REMOTEHOST " - " $DISPLAY 192.168.77.1 - 192.168.77.1:0.0
Modulo list-file |
|
Per sperimentare questo modulo (di tipo auth) ci poniamo
il seguente obiettivo:
vogliamo abilitare al login di ssh solo agli utenti
il cui nome è presente nel file /etc/sshusers-allowed.
# /etc/sshusers-allowed guest nane toni
poi configuriamo pam:
# /etc/pam.d/ssh
[...]
auth required pam_listfile.so item=user sense=allow \
file=/etc/sshusers-allowed onerr=fail
[...]
e quando proviamo a collegarci:
user@realHost$ ssh root@192.168.77.2
otterremo risposta negativa. Se proviamo ad usare l'utente
guest (con password not24get) otteniamo
invece l'accesso.
Modulo motd: output the motd file |
|
Questo modulo (di tipo session) è trascurato
dall'implementazione di ssh in quanto ssh
controlla tale funzionalità attraverso il file di configurazione
/etc/ssh/sshd_config:
# /etc/ssh/sshd_config [...] PrintMotd no
Per il servizio di login invece possiamo provare a sperimentarlo:
# /etc/pam.d/login session optional pam_motd.so
e quindi al login:
vHost login: root Password: root Welcome to Netkit4TIC!
Modulo last login |
|
Questo modulo (di tipo session anche se
è dichiarato di tipo auth!) è trascurato
dall'implementazione di ssh in quanto ssh
controlla tale funzionalità attraverso il file di configurazione
/etc/ssh/sshd_config:
# /etc/ssh/sshd_config [...] PrintLastLog no
Per il servizio di login invece possiamo provare a sperimentarlo:
# /etc/pam.d/login session optional pam_lastlog.so
e quindi al login:
vHost login: root Password: root Last login: Wed Feb 9 20:42:08 2005 on ttys/0
Modulo wheel |
|
Questo modulo (di tipo auth) coinvolge l'utilizzo
del comando su e del gruppo wheel.
Nel caso quest'ultimo non sia presente sul file /etc/group
occorre aggiungerlo:
root@vHost# groupadd wheel
Il comando su serve per diventare provvisoriamente un
altro utente sempre che se ne conosca la password. Il comando è
utilizzabile solo da root quando non abbia il bit
SUID impostato. In caso contrario tutti lo possono usare:
user@host$ ls -l `which su`
-rwsr-xr-x 1 root root 23416 Nov 26 07:30 /bin/su
Supponiamo ora che vogliamo restringere l'insieme degli utenti
abilitati ad eseguire il comando su. Diamo i comandi:
root@vhost# chown root:wheel /bin/su root@vhost# chmod u=rwxs,g=rx,o= /bin/su root@vhost# ls -l /bin/su -rwsr-x--- 1 root wheel 23416 Nov 26 07:30 /bin/su root@vhost# gpasswd -a guest wheel root@vhost# id guest uid=1000(guest) gid=1000(guest) groups=1000(guest),1003(wheel)
A questo punto abbiamo cambiato il funzionamento di su in modo
da permettere ai soli utenti del gruppo wheel
di diventare root. Ma se noi vogliamo che tutti gli utenti possano
usare su ma non per diventare root?
Allora ecco entrare nel gioco il modulo che stiamo analizzando:
root@vhost# chown root:wheel /bin/su
root@vhost# chmod u=rwxs,g=rx,o=rx /bin/su
root@vhost# ls -l /bin/su
-rwsr-xr-x 1 root wheel 23416 Nov 26 07:30 /bin/su
root@vHost# adduser toni
a questo punto configuriamo il modulo pam_wheel:
# /etc/pam.d/su [...] auth required pam_wheel.so
e ora lo mettiamo alla prova:
vHost login:toni Password: x toni@vHost$ id uid=1004(toni) gid=1004(toni) groups=1004(toni) toni@vHost$ su - Password: root su: Permission denied Sorry. toni@vHost$ su guest Password: not24get guest@vHost$ id uid=1000(guest) gid=1000(guest) groups=1000(guest),1003(wheel) guest@vHost$ su - Password: root root@vHost# id uid=0(root) gid=0(root) groups=0(root)
In pratica l'utente guest oltre a poter usare su
(come del resto anche l'utente toni) può diventare
root perchè appartiene al gruppo wheel.
Configurazione pam_opie (One Time Password) |
|
Questo modulo serve per implementare l'autenticazione utente in modo
da utilizzare password sempre diverse ad ogni login. Dopo averla
utilizzata infatti la password viene scartata e non sarà più
utilizzata.
I pacchetti necessari sono
libpam-opie che contiene il modulo PAM,
opie-server che serve per creare e gestire il
key file /etc/opiekeys e
opie-client che contiene i programmi per la generazione
di one-time password.
Per attivare la funzionalità occorre fare la modifica:
# /etc/pam.d/common-auth auth required pam_opie.so
In seguito occorre abilitare (o disabilitare) il
sistema per usare OPIE al login.
Abilitamo lo user guest:
root@vHost# opiepasswd guest Adding guest: You need the response from an OTP generator. New secret pass phrase: otp-md5 499 vH4281 Response:SANK MESH GILD TOP ALL HOT ID guest OTP key is 499 vH4281 SANK MESH GILD TOP ALL HOT
dove SANK MESH GILD TOP ALL HOT sono stati
ottenuti, in una seconda shell, con il comando (OTP generator):
user@realHost$ opiekey -5 499 vH4281 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: 1234567890 SANK MESH GILD TOP ALL HOT
Per conoscere la prossima password usabile e per controllare
che non raggiunga il valore 0 (in caso occorre usare nuovamente
opiepasswd):
root@vHost# opieinfo guest
498 vH4281
Ora è il momento di sperimentare il login OTP da ssh:
user@realHost$ ssh guest@192.168.77.2 otp-md5 498 vH4281 ext, Response:BEY SELL NUT ROSE HER HAVE guest@vHost$
dove BEY SELL NUT ROSE HER HAVE è stato calcolato,
in una seconda shell, con il comando (OTP generator):
user@realHost$ opiekey -5 497 vH0746 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Sorry, but you don't seem to be on the console or a secure terminal. Warning: Continuing could disclose your secret pass phrase to an attacker! Enter secret pass phrase:1234567890 BEY SELL NUT ROSE HER HAVE
Infine per disabilitare OPIE per lo user guest:
root@Vhost# opiepasswd -d guest Updating guest: Disable guest's OTP access? (yes or no)yes ID guest is disabled.
Ecco uno screenshot del desktop.
Sviluppo di un modulo in linguaggio C |
|
In un esempio della documentazione di PAM si parla di un genitore
che vuole aumentare la conoscenza delle "tabelline" dei suoi figli
utilizzando uno stratagemma: personalizza il login del pc di
casa che invece di chiedere la password domanda un valore da
calcolare e solo in caso positivo si rende operativo.
In seguito proveremo a realizzare questa funzionalità attraverso la
costruzione di un modulo PAM scritto in linguaggio C.
La costruzione di un modulo prevede la disponibilità del compilatore
gcc e delle librerie di sviluppo di pam ossia del
pacchetto libpam0g-dev. Supposto che il modulo si
chiami pam_calc.so i comandi per compilare, linkare e
spostare nella directory di competenza sono:
root@vHost# gcc -fPIC -c pam_calc.c root@vHost# ld -x --shared -o pam_calc.so pam_calc.o root@vHost# cp pam_calc.so /lib/security
Una prima bozza di implementazione di
questo modulo (di tipo auth) si trova nel file
pam_calc.c. Dalla
tipologia del modulo è obbligatorio implementare le
funzioni pam_sm_authenticate e pam_sm_setcred.
In seguito occorre anche implementare la particolare "conversazione
matematica" attraverso la funzione conversation.
Per provarlo con ssh abbiamo ritoccato il file
/etc/pam.d/ssh:
# /etc/pam.d/ssh auth sufficient pam_calc.so [...]
Ecco una tipica sessione in cui al secondo tentativo mostriamo
il funzionamento "a stack" attivato dalla specifica "sufficient"
nel file /etc/pam.d/ssh:
user@realHost$ ssh root@192.168.77.2 Ciao root, quanto fa 2 per 8 ? 16 root@vHost# exit logout Connection to 192.168.77.2 closed. user@realHost$ ssh root@192.168.77.2 Ciao root, quanto fa 6 per 9 ? 0 Password: root root@vHost#
|
|
Sandro Doro (email me)