Traduzioni: English - Italiano


Sezione 1: Introduzione ai permessi in Linux

Linux è oggi considerato da molti il sistema operativo più sicuro. Uno dei fattori chiave per la sicurezza di un sistema è il controllo dei permessi di accesso. Tutti i sistemi operativi moderni supportano questa funzione, che l'autore crede sia apparsa per la prima volta nel sistema operativo UNIX. Permette ai proprietari di file di porre dei limiti agli utenti che possono leggere, scrivere, ed eseguire o cambiare file, eseguire processi ("compiti") e ad altre parti del sistema.

Linux, come ogni SO simil-UNIX, ha un sistema incorporato di controllo dei permessi dei file. Assegna gli attributi seguenti ad ogni file nel suo file system:

Si può vedere il proprio utente e gruppo eseguendo il comando seguente in un emulatore di terminale (provare in gnome-terminal o konsole):

id -a

uid dice chi si è (come se non lo si sapesse già), gid è il proprio gruppo "effettivo" e grouppi sono tutti gli altri gruppi a cui si appartiene. Se a qualche gruppo a cui si appartiene è permesso un accesso, allora si ha l'accesso. L'id effettivo del gruppo è significativo quando si creano file e directory, come spiegato in seguito. Per la cronaca, quando si fa il login il proprio gruppo effettivo (cioè quello "reale" group) è impostato al proprio gruppo "primario": il gruppo associato al proprio login in /etc/passwd.

Termini usati:

file system - una struttura su disco che contiene la descrizione dei file (come gli attributi menzionati più sopra, la data di modifica dei file, ecc.) e il contenuto stesso dei file. I file system sono contenuti in partizioni sul disco (chiamate anche fette). I file system più popolari oggigiorno sono ext3, xfs e reiserfs. Se si usa Debian, probabilmente si usa ext3. È bene menzionare il fatto che le directory ('cartelle') sono anch'esse considerate file, che semplicemente contengono altri file. Perciò i permessi si applicano anche alle directory.

gruppo utente - nei sistemi simil-UNIX, ogni utente viene assegnato ad un qualche gruppo. Gli utenti nello stesso gruppo possono condividere diritti, per esempio i permessi di un file possono essere impostati in modo che tutti gli utenti di un gruppo possano modificare i suoi contenuti.

Sezione 2: I permessi UNIX spiegati

Una volta imparata la teoria, è bene passare alla pratica: che aspetto hanno i permessi UNIX e come usarli? Prima di tutto, si esaminino i permessi di un file di esempio. Eseguendo il comando seguente in una console o un emulatore di terminale Linux:

stat /etc/hostname

si vede un elenco degli attributi del file che include il tipo di file (potrebbe anche essere una directory, un collegamento simbolico, ecc.), la dimensione del file, ecc. ed una riga come quella sottostante che è quella interessante in questo caso:

Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)

Il file ovviamente appartiene all'utente root (l'amministratore di sistema) e al gruppo root. Dopo la barra inclinata sono mostrati gli ID utente numerici: questo è il modo in cui sono archiviati nel file system, al fine di risparmiare spazio su disco.

Il campo Access contiene un numero ottale e la sua rappresentazione in forma leggibile (personalmente considero la forma numerica più leggibile). È fondamentale sapere cosa significhi il numero dei permessi. È formato da quattro cifre, comprese tra 0 e 7. Per il momento la prima non viene presa in considerazione e vengono analizzate le ultime tre dato che sono quelle usate più comunemente su tutti i sistemi. Nell'esempio, queste cifre sono 644. Ogni cifra può essere la somma di 4, 2 e 1, ma non tutte le componenti devono essere incluse il che risulta in un possibile valore compreso tra 0 e 7. Di seguito sono elencati i significati di ciascuna componente della somma, con "soggetto" che rappresenta l'utente, il gruppo o gli altri, come spiegato in seguito.

Il numero 5, perciò, significa: permesso di leggere ed eseguire, ma non di scrivere.

Le cifre definiscono rispettivamente i permessi per il proprietario, il gruppo e tutti gli altri. Per tanto si può vedere che nell'esempio precedente, il proprietario del file (root) può scrivere nel file e leggere il suo contenuto, mentre il gruppo 'root' e gli altri utenti (che non sono root, né fanno parte del gruppo 'root') hanno il permesso di leggere il file.
Ora, si confrontino questi permessi con quelli del file /etc/shadow (usando nuovamente "stat"). Questo file ha 0 come terza cifra significativa, perciò gli utenti che non sono root né appartengono al gruppo "shadow" non possono nemmeno leggere il file. Si può facilmente verificarlo avviando un editor di testo e cercando di aprire /etc/shadow: come utente regolare non si dovrebbe essere in grado di vedere il suo contenuto dato che contiene le password a livello di sistema (e questo esula dallo scopo di questo piccolo ?HowTo).

Forma leggibile

Diversi strumenti di sistema e programmi grafici abbracciano l'idea di una forma leggibile: una stringa di 10 caratteri consecutivi. Per vederne un esempio, eseguire il comando seguente:

ls -l /etc

L'opzione -l dice a "ls" di visualizzare i permessi dei file nella colonna a sinistra dell'output. La sequenza completa che si può ottenere è simile alla seguente (anche se probabilmente non si troverà un file così in /etc):

-rwxrwxrwx+

Ora si suddivida questo in tre parti; il primo carattere definisce il tipo di nodo, che è - per i file normali, d per le directory, l per i collegamenti simbolici, c per i device a caratteri, p per i pseudo-terminali and b per i device a blocchi. I file, le directory e i collegamenti si trovano comunemente in tutto il file system, mentre i device e i pseudo-terminali dovrebbero essere presenti solo in /dev. Si hanno perciò 3 pezzi, ciascuno di 3 caratteri: rwx rwx rwx. Corrispondono esattamente alle rispettive cifre dei permessi: se un permesso è abilitato è presente una lettera, altrimenti è presente - al posto della lettera. In questo caso, il primo rwx corrisponde a 7 per il proprietario, il secondo è ancora 7 per il gruppo proprietario e il terzo corrisponde ai permessi per tutti gli altri (il "mondo"). Perciò, per esempio, 640 si traduce in:

rw-r-----

(rw- per il proprietario, r-- per il gruppo, --- per gli altri). L'ultima colonna contiene il segno +. È improbabile vederlo quando si elenca il contenuto di una directory (la colonna appare vuota), ma significa che sono attive regole estese per gli accessi, perciò i reali permessi del file non sono solamente quelli mostrati dalla modalità di accesso del file: si possono leggere informazioni su ACL più avanti in questo documento.

Una nota sulla gestione dei percorsi

Per accedere ad un qualunque percorso nel file system, l'utente (con cui viene eseguito un particolare processo) deve avere come minimo i permessi di esecuzione per tutte le directory genitrici. Perciò, se si tenta di accedere ad un file di esempio /etc/security/limits.conf, anche se questo ha una modalità 0755 (sempre nell'esempio ipotetico), non è necessariamente vero che si è liberi di leggerlo. Per leggere il file, si deve essere in grado di "eseguire" tutte le sue directory genitrici, perciò si devono avere i permessi di esecuzione per /etc e /etc/security. Se o /etc o /etc/security ha impostati dei permessi che non permettono di eseguirla (1), allora la lettura di /etc/security/limits.conf fallisce. Questa regola si applica a tutto il file system.

Impostazioni predefinite per file e directory nuovi

Questa sezione è presente principalmente per fornire materiale di riferimento e per aiutare nella comprensione. I permessi e l'assegnazione ad un gruppo predefiniti spesso non vengono modificati perciò si può saltare questa sezione e tornare a leggerla in seguito per avere ulteriori dettagli in caso di bisogno.

I permessi associati con i file e le directory appena creati sono, per la maggior parte, determinati da una cosa chiamata umask. Essa è un numero ottale di 4 cifre che viene sottratto da 0777 per ottenere i permessi associati ai nuovi oggetti creati nel file system. L'umask di un sistema Debian "standard" è 0022 e ciò fa sì che i permessi predefiniti siano 0755, cioè il proprietario ha tutti i permessi, il gruppo ha permessi di lettura ed esecuzione ma non di scrittura e tutti gli altri possono leggere ed eseguire ma non scrivere. Ci si potrebbe aspettare che tutti i nuovi file siano creati come eseguibili, ma ciò non avviene perché la chiamata di sistema che crea i file lo fa in modo predefinito come non eseguibili. Le directory invece hanno il bit di esecuzione impostato, se l'umask lo permette, e perciò possono essere, in modo predefinito, attraversate da tutti.

Il comando di shell umask può di solito essere usato (senza argomenti) per visualizzare la umask predefinita attuale. L'umask viene impostata globalmente dall'amministratore di sistema in uno di vari modi; il più elegante probabilmente è l'uso del modulo ?PAM pam_umask in /etc/pam.d/common-session. L'umask di sistema può essere aggirata da ciascun utente; ciò viene di solito fatto in ~/.bashrc per ciascun utente, con il comando shell umask per ciascun processo o usando la chiamata di sistema umask(2) dall'interno di un programma.

L'UID (numero ID utente) utente associato con un file o directory appena crati è quello effettivo del processo in esecuzione. Nella maggior parte dei casi queso è l'uid dell'utente che ha fatto il login e avviato il processo.

Il gruppo associato ad un file o directory appena creati è il gruppo "effettivo" del processo in esecuzione. Questo è solitamente il gruppo chiamato come il nome utente dell'utente che ha fatto il login, ma può essere manulmente modificato (insieme al gruppo "reale") per ciascun processo con il comando newgrp anche se ciò viene fatto di rado.

La prima delle 4 cifre ottali che rappresentano i permessi contiene i bit setuid e setgid. Queti possono essere usati per sovrascrivere alcune delle impostazioni predefinite descritte sopra, ma non è il caso di entrare nei dettagli tranne per far notare che l'idioma per progetti collaborativi gruppi privati degli utenti (vedere in seguito) dipende dal comportamento del bit setgid.

Sezione 3: Modificare i permessi dei file

Questa sezione mostra, usando un esempio, l'uso base del comando chmod. Chmod è uno dei migliori amici dell'amministratore di sistema ed è lo strumento standard per manipolare i permessi dei file in vari *nix (funziona anche in *BSD e Solaris!). Prima di tutto, creare un file a scopo dimostrativo; in questo esempio viene usato il nome testfile. I comandi che seguono vengono eseguiti in un emulatore di terminale o in una console Linux. Fondamentalmente si può semplicemente farne il copia&incolla e vedere come funzionano.

# prima di tutto, creare il file usando il comando touch (vedere "man touch" per i dettagli)
touch testfile
# ora, vedere i suoi permessi
stat testfile
# modificare il file in modo che i membri del gruppo e gli altri utenti possano scriverlo
chmod 666 testfile
# vedere i nuovi permessi
stat testfile

I permessi sono cambiati? Si può verificare se il comando ha veramente funzionato iniziando una nuova sessione facendo il login con un altro account utente, o usando il comando su nome_utente. Se si ha un solo account utente, crearne uno nuovo a scopo di test:

su
(inserire la password di root, per fare il login all'account root e aggiungere un utente di test)
adduser demo
# si può rimuovere questo utente una volta che si è finito usando: deluser demo

Ora, fare il login in demo, aprire testfile (nella directory home del proprio utente regolare) e digitarvi qualcosa. Salvare e poi controllare con il proprio account utente che nel contenuto ci sia qualsiasi cosa si è scritta. Voila! Si può ora voler controllare i vari permessi diversi. Provare ad usare chmod con argomenti come 644, 640 e così via.

Sezione 4: Esempi di scenari che chiamano in causa chmod

Si sa ora come cambiare i permessi dei file. Tuttavia come può essere utile farlo nella vita reale, a parte lasciare che i propri amici lascino un messaggio a caso nei propri file di testo?

Caso 1: Foto di famiglia

Situazione: Le foto di famiglia sono memorizzate nella directory Foto del proprio account utente. Altri membri della famiglia usano il computer e si vuole che siano in grado di accedere alle foto.

Domanda: Come impostare i permessi della directory affinché gli altri utenti possano vedere i propri file ed il loro contenuto?

Risposta: Impostare i permessi della directory a 755 e quelli dei file in essa contenuti a 644:

chmod 755 Foto
# Foto/* significa tutti i file nella directory Foto
chmod 0644 Foto/*

Caso 2: Software e file dati per il proprio dipartimento al lavoro

Situazione: Nella propria directory home c'è un programma ~/AppSoftware/programma.bin. Esso memorizza i file dati specifici per il proprio dipartimento in ~/NostriDati. L'amministratore di sistema ha assegnato a tutte le persone del proprio dipartimento il gruppo utente "miodipart". Si desidera che le altre persone del proprio dipartimento possano eseguire il software fornito e scrivere i file dati. Allo stesso tempo, ad altre persone al di fuori del gruppo dovrebbe essere permesso eseguire il software ma non modificare i dati. Per ragioni di semplicità non viene considerata la registrazione di chi ha aggiunto/rimosso dati (mantenere un registro è una necessità nella vita reale), ma solo l'attribuzione di permessi appropriati.

Domanda: Come permettere l'accesso in esecuzione per un gruppo ad un file (programma binario) e l'accesso in lettura-scrittura ad un'altra directory per lo stesso gruppo, negandolo allo stesso tempo agli altri utenti (mondo)?

Risposta: Per l'esempio nella situazione descritta, ciò si può ottenere con:

# qui di seguito: l'opzione -R ha effetto sulla directory e sui file/sottodirectory in essa
chmod -R 0755 ~/AppSoftware
chmod -R 0770 ~/NostriDati

Nel caso che i file abbiano l'attributo di gruppo impostato in modo sbagliato, si può correggerlo eseguendo come prima cosa chgrp -R miodipart file, dove "miodipart" è il nome del gruppo, "file" è il percorso dei file e l'opzione -R dice a chgrp di fare un'esecuzione ricorsiva (vedere l'esempio di codice precedente). Chgrp cambia il gruppo dei file in quello specificato.

Caso 3: File classificati

Domanda: Come proteggere file che devono rimanere segreti?

Risposta: Una protezione molto di base può essere ottenuta cambiando con chmod i permessi dei file/directory delicati in 0600. Tuttavia si tenga a mente che l'amministratore di sistema (root) può ancora accedervi, indipendentemente dai permessi dei file. Perciò, a parte bloccare i permessi dei file, è caldamente consigliabile cifrare i file usando un software di cifratura robusto (provare la cifratura gpg attraverso programmi come KGpg o vedere ccrypt: cifratura simmetrica).

Caso 4: Bit speciali

Domanda: Come disimpostare i bit speciali?

Risposta: Per rimuovere i bit speciali da un file dopo che sono stati impostati, è comodo usare i nomi simbolici. Ad esempio, se per sbaglio si imposta una directory con i permessi 6755, si possono usare i nomi simbolici dei bit speciali per disimpostarli. Quando si usano i numeri ottali che iniziano con la cifra 0, la propria shell potrebbe richiedere che il numero venga racchiuso tra virgolette '0755' per applicare i permessi in maniera corretta.

  chmod u-s,g-s /percorso/della/dir
  chmod '0755' /percorso/della/dir

Scenari di condivisione di gruppo di file ed i limiti dei permessi base UNIX

Gli esempi descritti in precedenza mostrano l'utilità dei permessi UNIX per i file. Si può accordare l'accesso ai propri file agli utenti del proprio gruppo, lasciare che i file siano visibili da tutti oppure mantenerli solo per sé stessi. Tuttavia esistono situazioni in cui questo modello di controllo degli accessi non è sufficiente.

Si ipotizzi di essere in un grosso sistema (un server, per esempio) e di fare parte, insieme a diverse dozzine di altri utenti, del gruppo "utenti". Ora, se si vogliono rendere disponibili alcuni dei propri file a un solo utente, senza che gli altri possano leggerlo, come possono essere utili i permessi UNIX? Si può in questo caso usare l'idioma per gruppi privati degli utenti per la condivisione di directory: una soluzione frequente per questo problema. Ma tale idioma spinge il sistema dei permessi UNIX al suo limite e ci sono casi, compresi casi di semplice condivisione di file tra 2 persone, in cui l'idioma è semplicemente non adatto.

Quando si raggiunge il limite dei permessi base UNIX per i file è arrivato il momento di usare...

ACL: elenchi di controllo degli accessi in Linux

ACL (Access Control Lists, elenchi di controlli degli accessi) sono un mezzo esteso per definire i diritti di accesso per i file e per oggetti. Permettono di specificare i permessi dei file in una maniera più dettagliata, assegnando a ciascun utente o gruppo (in aggiunta al proprietario e al gruppo impostati per il file) privilegi diversi. Per esempio, si può condividere un file solamente con uno specifico utente, indipendentemente dai gruppi a cui appartiene.

Come utilizzare questa nuova, potente funzionalità?

Per prima cosa, assicurarsi che il proprio sistema abbia il supporto per ACL. Prima di poter abilitare l'ACL per i propri file devono essere soddisfatti diversi requisiti. Controllare la versione del proprio kernel. Se è successiva a 2.6.18, allora è probabile che si abbia già internamente il supporto ACL. (Non sono sicurissimo sulla versione a partire dalla quale i kernel Debian abbiano ricevuto la patch per ACL). Il passo successivo è il pacchetto acl, necessario per la manipolazione degli attributi ACL. Lo si può installare con il comando:

 # se non si è fatto il login come root, usare prima "su"
apt-get install acl

In alternativa si può usare il gestore di pacchetti Synaptic, o un altro gestore di pacchetti, per scaricare ed installare il pacchetto. Se non si è l'amministratore di sistema, chiedere al proprio amministratore di abilitare l'ACL sulla macchina.
Una volta che acl è installato, si può provare a vedere se il proprio file system lo supporta. Un comando d'esempio è (assumendo che il file "testfile" esista):

setfacl --modify user:demo:5 testfile

Se setfacl si lamenta di un errore, probabilmente è necessario montare il proprio file system con l'opzione acl. Assumendo che il file "testfile" sia localizzato nel file system / , eseguire il comando seguente come root:

mount -o remount,acl /

Provare di nuovo setfacl. Se viene eseguito con successo, l'invocazione di:

getfacl testfile

dovrebbe mostrare, tra le altre cose, una riga come questa:

user:demo:r-x

Qui, rx significa permessi di "lettura e esecuzione", che sono equivalenti a 5. Per vedere se l'ACL funziona, impostare i permessi del file "testfile" a 700 usando chmod e cercare di aprirlo dall'account utente "demo". Se lo si può fare, l'ACL ha di fatto aggirato i permessi UNIX. Il proprio file system è ora pronto per un controllo granulare degli accessi con ACL!

Nota: per abilitare l'ACL in modo permanente per alcuni file system, si dovrebbe includere l'opzione acl in /etc/fstab. Fare riferimento alla pagina di manuale fstab(5) per istruzioni a riguardo.

Esempi di utilizzo di setfacl per gestire i permessi dei file

setfacl -R -m user:mario:6 filedir   # imposta permessi di lettura-scrittura per mario su filedir e tutto il suo contenuto
setfacl -m group:amministr-sist-junior:4 /var/log/apache2/error.log    # permette ai membri del gruppo amministr-sist-junior di leggere il file di registro degli errori di Apache2
setfacl -m user:cattivodavide:0 miei_appunti.txt    # impedisce all'utente cattivodavide di accedere a miei_appunti.txt

ACL predefiniti (ereditati)

Nota: un bug nei comandi cp e mv di coreutils limita la portata di quanto spiegato qui sotto alla semplice creazione di file, ad esempio con touch; con la copia e lo spostamento, la "maschera predefinita" della directory genitrice obiettivo non verrà ereditata come "maschera di accesso" per il file o la directory copiati o spostati: http://debbugs.gnu.org/db/85/8527.html

Gli ACL predefiniti sono uno strumento preziosissimo quando si crea una directory che si vuole condividere in lettura o scrittura tra diversi utenti. Questo suggerimento è stato ispirato da una discussione nel forum Debian: http://forums.debian.net/viewtopic.php?f=10&t=53591

Gli ACL predefiniti sono voci di controllo degli accessi che vengono ereditate da tutti i sotto-elementi di una directory (è permessa l'azione ricorsiva in profondità!). Perciò, se si vuole creare una directory per mario e giovanni in modo che entrambi possano lavorare sui file dell'altro, dovrebbero essere sufficienti i comandi elencati in seguito (notare l'opzione -d per setfacl che imposta un ACL predefinito):

mkdir spazio_comune
setfacl -m u:mario:7 spazio_comune
setfacl -d -m u:mario:7 spazio_comune
setfacl -m u:giovanni:7 spazio_comune
setfacl -d -m u:giovanni:7 spazio_comune

Nota all'esempio precedente: un ACL predefinito viene ereditato da tutti i nodi figli come voce ACL e come ACL predefinito, ma un ACL predefinito di per sé non comporta alcuna azione relativa ai permessi: da qui la necessità di comandi doppi. Il primo comando dà all'utente "mario" il permesso di scrittura, lettura ed esecuzione per la directory, e il secondo imposta l'ACL predefinito che verrà ereditato.

Ora, ogni volta che viene creato un file, esso mantiene proprietario e gruppo originali, ma ad esso dovrebbero essere automaticamente assegnati gli ACL definiti in precedenza. Questo è utile, ad esempio, quando si hanno utenti che collaborano allo sviluppo di un sito web. Si può usare Apache o PHP in esecuzione come www-data, scrivere uno script per cambiare, al momento della creazione, il proprietario del file in www-data (inotify è di aiuto!), e tutti i file continuano ad essere scrivibili da mario e giovanni, gli sviluppatori Web.

Appendice: alcuni suggerimenti

  adduser io altroutente # aggiunge l'utente "io" al gruppo "altroutente"

In seguito "altroutente" deve semplicemente impostare i propri file a 0750 o qualsiasi altra impostazione di permessi desideri. Questa è, tuttavia, la vecchia maniera di affrontare i permessi granulari per i file e dovrebbe essere, quando possibile, evitata usando piuttosto i gruppi privati degli utenti o ACL.

Questo è tutto! Buon divertimento e grazie dell'ascolto.


CategoryCommandLineInterface