Home > GNU/Linux, Sicurezza e GNU/Linux > Sicurezza e GNU/Linux (6): SetUID e le Capabilities

Sicurezza e GNU/Linux (6): SetUID e le Capabilities

Abbiamo visto nelle puntate precedenti come si possano concedere privilegi ad un utente (o a un software) in modo che possa compiere azioni normalmente riservate all’utente root. Vedremo ora come fare qualcosa di simile ma senza usare i permessi di utenti e gruppi, cioè non sfruttando il modello di sicurezza tradizionale di Unix.

Le capabilities sono, come si intuisce dal nome, delle “capacità” che il sistema operativo può concedere ad un processo in esecuzione o anche ad un file eseguibile (che una volta caricato diventerà un processo).

Le capabilities sono definite da alcune bozze dello standard POSIX (quello che definisce i sistemi Unix) ma non sono mai diventate ufficiali.

Partiamo però dal capire a cosa ci possono servire. Alcuni programmi, ad esempio il banale ping, hanno bisogno di compiere azioni che solo l’utente root può fare. Nel caso di ping, si tratta precisamente di aprire un raw socket per (provare) a connettersi all’host remoto. Un raw socket è, in parole povere, una connessione che salta le normali procedure del sistema operativo e permette la comunicazione tra l’applicazione e la macchina remota senza rispettare i limiti imposti dal sistema operativo. Più precisamente, un raw socket permette l’invio di pacchetti senza l’incapsulamento che il sistema operativo normalmente opererebbe per rispondere agli standard di protocollo, (permettendo così al programma, ad esempio, di reimplementare il protocollo stesso senza tenere conto di come esso è realizzato nel sistema operativo in uso). Per questo, essendo una operazione a basso livello, solo l’utente root può eseguirla.

Ora però il comando ping serve anche agli utenti normali per controllare se un certo computer in rete è raggiungibile o no. Per questo, esso viene dotato del bit SUID, di cui abbiamo già parlato. Un file eseguibile che abbia attivato il flag SUID, può cambiare il suo “padrone”, per cui, anche se lanciato da un utente normale, può diventare un processo eseguito con i privilegi di root.

Proviamo a dare il seguente comando:

ping 127.0.0.1

che non serve ad altro che a pingare noi stessi. Ora apriamo un altro terminale e diamo:

ps aux | grep ping

otteniamo

guido 8027 0.0 0.0 1988 524 pts/2 S+ 18:21 0:00 ping 127.0.0.1

noteremo che ping è eseguito come nostro utente, al che sembrerebbe che non c’è nulla di anomalo. In realtà, non esiste un solo identificativo dell’utente (UID) per ogni processo, ma più di uno. In particolare, nel nostro caso è interessante distinguere tra il Real UID e l’Effective UID. Il primo è l’UID del processo che lancia il nostro processo (ovvero il processo padre) e che trasferisce questa proprietà al processo figlio. Ma se il processo figlio è un eseguibile con il flag SUID settato, allora esso sarà capace di cambiare l’Effective UID, ossia quello che il kernel prende davvero in considerazione se deve impedirgli o meno di compiere una azione.

Difatti, il comando ping ha il SUID settato come si vede subito con:

ls -l /bin/ping

che restituisce:

-rwsr-xr-x 1 root root 34756 2010-03-12 00:12 /bin/ping

notare la tripletta “rws” al posto della normale rwx.

Proviamo ora a togliere il SUID al file /bin/ping e vediamo che accade:

sudo chmod u-s /bin/ping
ls -l /bin/ping

otteniamo

-rwxr-xr-x 1 root root 34756 2010-03-12 00:12 /bin/ping

L’eseguibile non può più “diventare” root e, difatti, se proviamo ad usarlo otteniamo un bell’errore

guido@guido-m:~$ ping 127.0.0.1
ping: icmp open socket: Operation not permitted

Ed ora? Ora arrivano le nostre capabilities. Invece di permettere a ping di cambiare il suo Effective UID, gli permettiamo solo di compiere l’azione che davvero gli serve, cioè aprire un socket raw. Per fare ciò, installiamo le utility necessarie a cambiare le capabilities dei file e poi assegniamo a /bin/ping la giusta capability.

sudo apt-get install libcap2-bin
sudo setcap cap_net_raw=ep /bin/ping
ping 127.0.0.1

e il nostro ping tornerà magicamente a funzionare. Stavolta, però, qualora esso contenga una falla, sarebbe una minaccia molto più debole: difatti ping non potrebbe eseguire qualsiasi operazione permessa a root ma soltanto quella che noi abbiamo deciso di autorizzare.

Le capabilities sono in genere poco sfruttate nelle distribuzioni GNU/Linux in quanto vengono considerate una tecnica di hardening (rafforzamento) riservata agli amministratori di sistema più esperti. Qualora voleste avere una panoramica sulle capabilities vi consiglio queste fonti:

POSIX Capabilities – Gentoo Wiki

Using File Capabilities Instead Of Setuid – ArchWiki

  1. threshold
    18 maggio 2011 alle 19:21

    Come al solito grazie per i post interessantissimi!
    Ho fatto subito una prova e ho notato che in quasi tutte le distribuzioni che ho nel mio fedele netbook (arch, debian, slackware) è effettivamente settato il flag suid in ping, l’unica a non avercelo è fedora (15 ma non so se con la 14 fosse lo stesso). effettivamente fedora punta molto sulla sicurezza da quel che so (selinux… tanto per suggerire/sperare un prossimo articolo) quindi devo presumere che fedora sia tra le poche distribuzioni a sfruttare le capabilities?
    grazie ancora e ciao!
    ps: dici che la foto arrapi per via del manuale?🙂

  2. threshold
    18 maggio 2011 alle 19:35

    ho fatto qualche ricerca e questo link (http://fedoraproject.org/wiki/Features/RemoveSETUID) sembra offrire una risposta. resta valido però l’invito su selinux!!

    • 18 maggio 2011 alle 22:30

      ne parlerò insieme ad apparmor

  3. Cippaciong
    18 maggio 2011 alle 23:13

    Sarò di parte ma la wiki di arch non delude mai =)
    Un articolo sui firewall e’ sempre in programma??
    Grazie intanto per tutti questi ottimi articoli. Credo che, tempo/voglia dovresti scriverne di più (leggasi di diversi argomenti) perchè permettono a tutti di avvicinarsi in modo semplice ad argomenti avanzati

    • 18 maggio 2011 alle 23:45

      sì è in programma. Non solo, nel mio repo ho messo l’ottimo configuratore di firewall di fedora, uno spettacolo.

      • Cippaciong
        22 maggio 2011 alle 18:16

        Eheh…sono su arch da tempo ormai quindi non uso più i tuoi repo come una volta.
        In ogni caso dubito che su arch manchi, per lo meno in AUR.
        Grazie del consiglio!

  4. hug
    19 maggio 2011 alle 22:35

    Sono contento che non sia terminato il corso di sicurezza. Mi sto segnando , tra una puntata e l’altra, le domande da porti ma su LQH non c’é la sezione “Sicurezza” dove le dovrò postare ? ciao

  5. 20 maggio 2011 alle 1:47

    Interessantissimo post!

  1. 21 maggio 2011 alle 19:34

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: