5. Sicurezza dei file e dei filesystem

Alcuni minuti di preparazione e pianificazione prima di mettere in funzione i sistemi possono essere d'aiuto per proteggere loro e i loro dati.

5.1. Settaggi di umask

Il comando umask può essere usato per stabilire la modalità standard di creazione dei file nel sistema. È il complementare ottale della modalità desiderata. Se i file venissero creati senza tenere in conto i settaggi dei loro permessi, un utente potrebbe inavvertitamente dare permessi di lettura o scrittura a qualcuno che non li dovrebbe avere. I tipici settaggi di umask includono 022, 027 e 077 (che è il più restrittivo). Normalmente la umask viene impostata in /etc/profile, così che abbia effetto su tutti gli utenti sul sistema. I permessi risultanti vengono calcolati come segue: i permessi predefiniti di proprietario/gruppo/altri (7 per le directory, 6 per i files) sono combinati con la maschera invertita (NOT) eseguendo un'operazione AND bit per bit.

Esempio 1:

file, permesso predefinito 6, binario: 110 maschera, per es. 2: 010, NOT: 101

permessi risultanti, AND: 100 (uguale a 4, r__)

Esempio 2:

file, permesso predefinito 6, binario: 110 maschera, per es. 6: 110, NOT: 001

permessi risultanti, AND: 000 (uguale a 0, ___)

Esempio 3:

directory, permesso predefinito 7, binario: 111 maschera, per es. 2: 010, NOT: 101

permessi risultanti, AND: 101 (uguale a 5, r_x)

Esempio 4:

directory, permesso predefinito 7, binario: 111 maschera, per es. 6: 110, NOT: 001

permessi risultanti, AND: 001 (uguale a 1, __x)


		# Imposta la maschera di default degli utenti
		umask 033
Assicuratevi che la umask di root sia 077, che impedirà la lettura, scrittura ed esecuzione ad altri utenti, eccetto che per quei file che siano stati esplicitamente cambiati con chmod. In questo caso, le nuove directory avrebbero permesso 744, ottenuto sottraendo 033 da 777. I nuovi file avrebbero permesso 644.

Se usate RedHat, e aderite al loro schema di creazione di ID di utenti e gruppi (User Private Groups), sarà sufficiente usare 002 per la vostra umask. Questo è dovuto al fatto che la configurazione di default è di un utente per gruppo.

5.2. Permessi dei file

È importante assicurarsi che i file di sistema non siano aperti da utenti e gruppi che non dovrebbero fare manutenzione di sistema.

Unix separa il controllo di accesso ai file e alle directory secondo tre caratteristiche: proprietario, gruppo e altri. C'è sempre un solo proprietario, un numero variabile di membri del gruppo, e tutti gli altri.

Ecco una veloce spiegazione dei permessi di Unix:

Proprietà - Quale/i utente/i e gruppo/i ha controllo sui permessi del nodo.

Permessi - Bit che possono essere settati o resettati per concedere certi tipi di accesso. I permessi delle directory possono avere significati diversi dai corrispondenti permessi sui file.

Lettura:

Scrittura:

  • Poter aggiungere parti o fare modifiche a un file

  • Poter cancellare o spostare i file in una directory

Esecuzione:

  • Poter eseguire un programma binario o script di shell

  • Poter eseguire una ricerca nella directory, nel caso abbia il permesso di lettura

Attributo Save Text: (per le directory)

Anche lo "sticky bit" ha un significato diverso quando applicato a directory e quando a file. Se lo sticky bit è impostato per una directory, allora un utente può solo cancellare file di cui è proprietario o di cui ha espliciti permessi di scrittura, anche se ha accesso in scrittura alla directory. Ciò è stato progettato per directory come /tmp, che sono scrivibili a tutti, ma in cui si preferisce che non tutti possano cancellare file a volontà. Lo sticky bit è segnato come una t nel listato lungo di una directory.

Attributo SUID: (per i file)

Descrive permessi set-user-id sul file. Quando la modalità di accesso set user ID è impostata nei permessi del proprietario, e il file è eseguibile, i processi che lo eseguono hanno accesso alle risorse di sistema basati sul proprietario del file, invece che sull'utente che ha creato il processo. Questa è la causa di molti exploit basati sul buffer overflow.

Attributo SGID: (per i file)

Se impostato nei permessi del gruppo, questo bit controlla lo stato "set group id" di un file. In pratica si comporta come SUID, solo che ha effetto sul gruppo. Il file deve essere eseguibile perché questo abbia effetto.

Attributo SGID: (per le directory)

Se si imposta il bit SGID su una directory (con chmod g+s directory), i file creati in quella directory avranno il gruppo impostato sul gruppo della directory.

Voi - Il proprietario del file

Gruppo - Il gruppo a cui si appartiene

Tutti - Chiunque non sia il proprietario o membro del gruppo

File di esempio:


        -rw-r--r--  1 kevin  users         114 Aug 28  1997 .zlogin
        1° bit - directory?             (no)
         2° bit - lettura per il proprietario?         (si, per kevin)
          3° bit - scrittura per il proprietario?        (si, per kevin)
           4° bit - esecuzione per il proprietario?      (no)
            5° bit - lettura per il gruppo?         (si, per users)
             6° bit - scrittura per il gruppo?        (no)
              7° bit - esecuzione per il gruppo?      (no)
               8° bit - lettura per tutti?      (si, per tutti)
                9° bit - scrittura per tutti?     (no)
                 10° bit - esecuzione per tutti?  (no)

Le seguenti linee sono esempi dei permessi minimi richiesti per l'accesso descritto. Forse vorrete dare più permessi di quanto vedete qui, ma questo mostra solo ciò che questi permessi minimi sui file fanno:


-r--------  Permette accesso in lettura al file per il proprietario
--w-------  Permette al proprietario di modificare o cancellare il file
            (Notate che chiunque con permesso di scrittura alla directory
            in cui si trova il file ha lo stesso privilegio)
---x------  Il proprietario può eseguire questo programma, ma non script
            della shell, che hanno bisogno anche del permesso in lettura
---s------  Il file verrà eseguito con User ID = utente
--------s-  Il file verrà eseguito con Group ID = gruppo
-rw------T  Non viene segnata l'ultima modifica. Usato spesso per file di swap
---t------  Nessun effetto. (Era lo sticky bit)

Esempio di directory:

        drwxr-xr-x  3 kevin  users         512 Sep 19 13:47 .public_html/
        1° bit - directory?             (si, contiene molti file)
         2° bit - lettura per il proprietario?         (si, per kevin)
          3° bit - scrittura per il proprietario?        (si, per kevin)
           4° bit - esecuzione per il proprietario?      (si, per kevin)
            5° bit - lettura per il gruppo?         (si, per users)
             6° bit - scrittura per il gruppo?        (no)
              7° bit - esecuzione per il gruppo?      (si, per users)
               8° bit - lettura per tutti?      (si, per tutti)
                9° bit - scrittura per tutti?     (no)
                 10° bit - esecuzione per tutti?  (si, per tutti)

Le seguenti linee sono esempi dei permessi minimi richiesti per l'accesso descritto. Forse vorrete dare più permessi di quanto vedete qui, ma questo mostra solo ciò che questi permessi minimi sulle directory fanno:


dr--------  I contenuti possono essere listati, ma gli attributi dei file non
            possono essere letti
d--x------  La directory può essere aperta e usata nei percorsi di
            esecuzione
dr-x------  Gli attributi dei file possono essere letti dal proprietario
d-wx------  I file possono essere creati/cancellati, anche se la directory non
            è quella corrente
d------x-t  Impedisce che i file siano cancellati da chi ha i permessi in
            scrittura. Usato su /tmp
d---s--s--  Nessun effetto

I file di configurazione del sistema (di solito in /etc) sono in genere in modo 640 (-rw-r-----), e proprietà di root. A seconda delle necessità di sicurezza del sistema si può cambiare questa impostazione. Non si lasci mai che dei file di sistema siano scrivibili da un gruppo o da tutti. Alcuni file di configurazione, incluso /etc/shadow, dovrebbero essere leggibili solo da root, e le directory in /etc non dovrebbero essere accessibili da altri.

Script della shell con SUID

Gli script della shell con SUID sono un serio rischio per la sicurezza, per cui il kernel non li considererà. A prescindere da quanto pensate che lo script sia sicuro, può essere sfruttato per dare a un cracker una shell di root.

5.3. Controllo dell'integrità

Un altro ottimo modo per rilevare attacchi locali (e anche di rete) è eseguire un programma che faccia un controllo d'integrità come Tripwire, Aide o Osiris. Questi programmi eseguono una serie di controlli su tutti i binari importanti e sui file di configurazione e li compara con un database di valori precedenti che si presumono corretti. In questo modo, ogni cambiamento nei file verrà segnalato.

È una buona idea installare questo tipo di programmi in un floppy e quindi proteggerlo fisicamente dalla scrittura. Così degli intrusi non potranno sabotare il programma per il controllo o cambiare i database. Una volta che è stato impostato un programma del genere, è una buona idea eseguirlo come parte dei compiti amministrativi di routine per vedere se qualcosa è cambiato.

Potreste persino aggiungere un elemento al crontab per eseguire il controllo dal floppy ogni notte e inviarvi un e-mail con i risultati al mattino. Qualcosa come:

		# imposta mailto
		MAILTO=kevin
		# esegui Tripwire
		15 05 * * * root /usr/local/adm/tcheck/tripwire 
vi spedirà un rapporto ogni mattina alle 5:15.

I controlli d'integrità possono essere una manna dal cielo per rilevare intrusioni prima che possano essere notate in altri modi. Dato che molti files cambiano durante il normale uso del sistema, si deve fare attenzione a cosa è dovuto all'attività di un cracker e cosa a quello che si sta facendo.

Si può trovare la versione open source e gratuita di Tripwire presso http://www.tripwire.org. Manuali e supporto sono invece a pagamento.

Aide si trova presso http://www.cs.tut.fi/~rammer/aide.html.

Osiris si trova presso http://www.shmoo.com/osiris/.

5.4. Cavalli di Troia

"Cavalli di Troia" prende il nome dal famoso inganno nell'Eneide di Virgilio. Il concetto è che un cracker distribuisce un programma o un binario che sembra attraente, e incita altre persone a scaricarlo ed eseguirlo come root. A quel punto il programma può compromettere il loro sistema mentre non se lo aspettano. Mentre pensano che il programma che hanno preso faccia una cosa (e magari la fa davvero), compromette anche la sicurezza del sistema.

Si dovrebbe controllare quali programmi vengono installati sulla macchina. RedHat fornisce checksum MD5 e firme PGP sui suoi pacchetti RPM perché si possa verificare ciò che viene installato. Altre distribuzioni hanno metodi simili. Non si dovrebbero mai eseguire binari che non si conoscono, di cui non si ha il sorgente, come root. Ovviamente pochi intrusi rilasciano il codice sorgente al pubblico.

Per quanto possa essere complesso, si prendano sempre i sorgenti di un programma dal suo vero sito di distribuzione. Se il programma deve essere eseguito da root, si controllino i sorgenti o si facciano controllare da qualcuno di cui ci si fida.