:: ESP - Lezione del 5 fiorile 216 (24 aprile 2008) ::
Torna alla pagina di ESP
Apache
Vediamo ora come si gestisce la sicurezza nel webserver Apache.
In ogni cartella che il server servirà può essere contenuto un file .htaccess (sì, c'è un puntino davanti, che vuol dire che è un file nascosto). Questo file fa testo per la dir in cui è contenuto. Altrimenti, si usa l'.htaccess della cartella superiore etc.
Il modulo mod-access supporta sia i permessi (allow) che le negazioni (deny). Permessi o negazioni possono essere supportati da direttive host-based, cioè che si applicano a tutto il sito, oppure a direttive user-based, ovvero basate sull'utente che si identifica.
Host-based
- allow from host-or-network/all
- deny from host-or-network'/all
Al posto di host-or-network devo mettere gli indirizzi di chi voglo alloware o denyare. Posso usare tutte le simpatiche forme che abbiamo visto con il Damiani: CIDR, maschere e così via.
Altrimenti, posso usare le forme
- allow from env = env-variable
- deny from env = env-variable
env-variable è una variabile che viene recuperata dall'header http. Il modulo mod-setenvif è in grado di controllare queste variabili.
Per esempio:
SetEnvIf Referer www.swappa.it internal_site
Allow from env = internal_site
Queste due righe mi dicono
- che considero www.swappa.it come internal_site quando appare nel campo referer dell'header http
- che tutti quelli in cui env = internal_site sono allowati
Il referer, nella fattispecie, è la pagina da cui sono arrivato alla pagina attuale. Questo vuol dire che se accedo da www.swappa.it, ok, altrimenti no.
User-based
Sono di 3 tipi:
- require user username username ...
- require group group group ...
- require valid-user
Nel primo caso, richiedo che l'utente sia uno che compare nella mia lista.
Nel secondo, voglio che il gruppo dell'utente compaia nella lista.
Nel terzo caso, voglio che l'utente si sia loggato con successo nel sistema.
Satisfy & order
Comunque le direttive host- e user-based non sono mutuamente esclusive. Anzi, la direttiva satisfy mi serve per stabilire come queste debbano interagire
- satisfy all = tutte due devono essere soddisfatte
- satisfy any = almeno una deve essere soddisfatta
Inoltre, c'è la direttiva order che dice l'ordine di valutazione di allow e deny
- order deny, allow = prima valuto le deny, poi le allow => realizzo di fatto una politica aperta
- order allow, deny = prima allow, poi deny => politica chiusa
- order mutual-failure = una richieste deve NON soddisfare deny, e SODDISFARE allow: in pratica non sono ammessi conflitti, se ci sono non va bene e non permetto l'accesso.
Granularità
La granularità mi dice a che livello di risorse controllo gli accessi. Posso controllare a livello di file o di metodo.
Il controllo a livello di file imposta direttive su un singolo file:
<FileMatch reg-exp>
...direttive...
</FileMatch>
Quello che succede è che tutti i file il cui nome soddisfa l'espressione regolare (reg-exp) indicata, saranno soggetti alle direttive scritte in mezzo.
A livello di metodo, invece, controllo in base a quale metodo l'utente utilizza. I metodi sono i vari GET, POST, PUT etc. di HTTP.
<limit GET POST PUT>
...direttive...
</limit>
Gerarchia di controllo
Come dicevamo all'inizio, posso mettere un file .htaccess in ogni dir, e farà testo per il contenuto di quella dir. Se non è presente, ci si rifà alla dir superiore e così via.
In pratica si applica una politica mstp, in cui si parte dalla directory principale che ospita il server, e si scende via via fino a trovare l'elemento più specifico vicino all'oggetto che voglio controllare.
Linux
Adesso vediamo invece come è gestita la sicurezza in Linux e, più in generale, nei sistemi Unix-based.
Ogni utente ha un UID e un GID. Lo UID è un numero intero univoco per ogni utente, mentre il GID è un numero che indica un gruppo. Un utente appartiene come minimo ad un gruppo che porta il suo stesso nome (eg. l'utente Patrizia farà parte del gruppo Patrizia), ma può anche appartenere ad altri gruppi.
Il file che contiene le associazioni tra nome utente e password è /etc/shadow, mentre per i gruppi c'è il file /etc/group che ha una lista di gruppi, e per ogni gruppo ha scritto accanto chi ne fa parte.
I file invece sono assegnati ad un UID e ad un GID, in genere quelli dell'utente che li ha creati. Posso cambiare proprietario e gruppo con i comandi chown e chgrp.
Ogni file ha una lista di 9 privilegi, divisi in 3 parti. La prima parte riguarda i privilegi che il proprietario del file ha sul file. La seconda parte contiene i privilegi dei membri del gruppo cui appartiene il file, mentre la terza parte contiene i privilegi di tutti gli altri.
I privilegi sono di tre tipi: r = read, w = write e x = execute. Ecco un esempio di stringa dei privilegi:
rwxr-xr--
Questa stringa la dividiamo in tre parti: rwx, r-x, r--
- rwx = è la parte relativa al proprietario, che ha i 3 permessi r, w ed x
- r-x = è la parte relativa ai membri del gruppo del file. Il - vuol dire che NON c'è il permesso w, ma solo r ed x, che infatti sono indicati
- r-- = è la parte relativa a tutti gli altri, che qui hanno solo il permesso r
L'esempio dovrebbe aver chiarificato la cosa. I permessi possono anche essere rappresentati in binario o in ottale, e si cambiano con chmod.
Ci sono anche i privilegi addizionali:
- sticky bit = si applica solo a dir. Dice che solo il proprietario del file E della dir può rimuovere o rinominare i files contenuti in quella dir
- setuid = lo UID del processo che esegue il file eseguibile NON è più l'UID dell'utente che lo lancia, ma è l'UID del PROPRIETARIO del file. Poi spieghiamo meglio.
- setgid = come setuid, ma per i gruppi.
setuid e setgid
Ecco come funziona.
I programmi sono dei file nel computer, e come tutti gli altri file hanno dei permessi, un proprietario e così via.
Supponiamo di avere un programma di sistema, come ctslt che sta per cancella tutto senza lasciare traccia. E il proprietario di ctslt è root, cioè l'amministratore.
Se io, utente Dario, eseguo il programma, il processo che ne deriva funzionerà, ma avrà solo i miei permessi. Ciò vuol dire che posso cancellare tutto senza lasciare traccia, ma solo se i files sono accessibili a ME.
Se invece imposto setuid, allora la riga dei permessi cambia:
rwxr-x--- diventa rwxr-x---
C'è una s minuscola nella parte relativa agli altri utenti: ciò vuol dire che posso eseguirlo come se avessi i privilegi del proprietario.
Questo vuol dire che posso fare come se fossi root, con quel processo, e quindi è una cosa rischiosa e apre potenziali falle di sicurezza.
Il setgid funziona allo stesso modo, ma per i gruppi.
Se imposto il setuid, o il setgid, ma il file NON è eseguibile, allora invece di una s minuscola esce una S maiuscola.
Determinazione dei privilegi
I privilegi vengono controllati prima in base all'identità dell'utente, poi in base al suo gruppo, ed infine in base ai permessi relativi a tutti gli altri.
Torna alla pagina di ESP
