REMUS: Un sistema operativo con protezione avanzata

Transcript

1 REMUS: Un sistema operativo con protezione avanzata MASSIMO BERNASCHI - Istituto Applicazioni del Calcolo, CNR EMANUELE GABRIELLI and LUIGI V. MANCINI - Università di Roma Traduzione italiana a cura dell ing. Giordano Pezzola giordano.pezzola@gmail.com Presentiamo una dettagliata analisi delle System Call UNIX e le classifichiamo secondo il loro livello di minaccia rispetto alla penetrazione del sistema. Basandoci su questi risultati, proponiamo un meccanismo efficace per controllare l invocazione delle system call più critiche dal punto di vista della sicurezza. L integrazione all interno del sistemi operativi UNIX esistenti è effettuata equipaggiando il codice delle system call in modo che l esecuzione delle stesse è permessa solo nel caso in cui il processo chiamante e il valore degli argomenti soddisfi le regole mantenute in un database di controllo degli accessi. Questo metodo non richiede modifiche nelle strutture dati e negli algoritmi del kernel. Tutte le modifiche del kernel sono trasparenti ai processi delle applicazioni che continuano a funzionare correttamente senza il bisogno di modifiche o ricompilazioni del codice sorgente. Un prototipo funzionante è stato implementato come modulo caricabile del kernel per il sistema operativo Linux. Il prototipo è in grado di rilevare e bloccare qualsiasi attacco in cui un attaccante prova a ottenere l accesso diretto al sistema come utente privilegiato. 1. Introduzione La maggior parte delle tecniche per il rilevamento delle intrusioni attualmente in uso sono basate su alcune forme di analisi della revisione dei dati e dei log files di sistema [Intrusion Detection Systems 1999; Lunt 1993]. L idea è di esaminare queste sorgenti di dati per provare delle operazioni o delle tecniche conosciute nell essere usate in particolari tipi di attacchi. I metodi di rilevamento delle intrusioni che guardano a questo tipo di indicatore sono conosciuti come Signature- based methods. Un secondo approccio, conosciuto come profile- based methods, prova a cercare anomalie (ad esempio login di root nelle ore non lavorative) e controlla periodicamente la configurazione del sistema cercando dei cambiamenti inaspettati (e.g. un utente sconosciuto con privilegi speciali). Per esempio, una pratica comune è eseguire su base regolare una comparazione tra le proprietà (dimensioni, permessi di accesso etc) di file di sistema e di una lista di riferimento. Questa procedura ha l obiettivo di trovare i Trojan Horses, ossia dei programmi lasciati da un intruso che sembrano innocui ma gli permettono di prendere pieno possesso del controllo del sistema. Il vantaggio principale di questo metodo è il suo essere non- invasivo; cioè non richiede cambiamenti al sistema operativo o ai comandi di sistema. Comunque, molto spesso rilevano l attacco quando già è terminato. Infatti, la ricerca in questa area si è focalizzata principalmente sulla rilevazione delle intrusioni dopo che l attacco è avvenuto con successo, più che prevenirlo prima che avvenga. La prevenzione delle intrusioni potrebbe essere raggiunta se il SO potesse monitorare ogni chiamata di sistema fatta da ogni processo e prevenire invocazioni a sistema maligne o inaspettate dall essere completate. Per esempio il SO potrebbe costruire un profilo di

2 invocazioni legali di system call (delle regole di sicurezza) per ogni processo applicativo in modo che il SO stesso possa immediatamente rilevare una violazione di sicurezza monitorando le system calls invocate durante l esecuzione del servizio, e in tal modo evitare che gli intrusi riescano ad abbattere la sicurezza del sistema. Un analisi delle system calls è cruciale per progettare e implementare un sistema di monitoraggio delle stesse in maniera efficace. Presentiamo una classificazione completa delle system calls UNIX in base al loro livello di minaccia. L analisi delle system calls descritta considera varie minacce incluse le penetrazioni con pieno controllo del sistema e gli attacchi di tipo Denial Of Service. Comunque, l attenzione delle nostre considerazioni e il progetto del prototipo presentato si riferisce principalmente alle minacce per le quali un intruso prova ad ottenere accesso diretto al sistema come utente privilegiato (root). I nostri risultati identificano e isolano un subset di system call e un subset di task critici per la sicurezza del sistema e quindi permettono la riduzione dell overhead del monitoraggio e lo sforzo di sviluppo e manutenzione. Come applicazione di questa metodologia, abbiamo sviluppato il prototipo REMUS (Reference Monitor for UNIX Systems) per il monitoraggio di quelle system calls che potrebbero essere usate per sovvertire l esecuzione di applicazioni privilegiate. REMUS impiega un semplice meccanismo per l intercettazione delle system calls a livello del kernel del sistema operativo e richiede delle aggiunte minimali al codice del kernel e nessun cambiamento della sintassi e della semantica delle system calls esistenti. In pratica, l esecuzione delle system calls è permessa solo nel caso in cui il processo che le invoca e il valore dei parametri soddisfi le regole tenute in un database di controllo dell accesso (ACD) all interno del kernel. Le tecniche di penetrazione comuni che ingannano il sistema ad eseguire il codice dell intruso in modalità privilegiata vengono bloccati da questo approccio. In particolare, REMUS blocca gli attacchi di tipo Buffer Overflow prima che possano completarsi. Bisogna notare che questi sono solo esempi di possibili attacchi, dato che il nostro approccio intende proteggere contro qualsiasi tecnica che consenta un attaccante di dirottare il controllo di un processo privilegiato. In aggiunta, la nostra soluzione permette di scegliere alcune opzioni di risposta nella gestione di un attacco. Le problematiche principali trattate da questo lavoro possono essere riassunte come segue: Offrire una completa analisi delle system calls critiche dal punto di vista della sicurezza Rilevare invocazioni illegali di system calls critiche prima che possano essere completate in modo da prevenire l attaccante dal dirottare il controllo di qualsiasi processo privilegiato. Permettere un controllo efficiente dei valori dei parametri delle system calls. Implementare un sistema operativo sicuro con l ausilio di estensioni leggere del kernel, in particolare senza richiedere cambiamenti nelle strutture dati e negli algoritmi esistenti. Supportare grazie all immediato rilevamento di possibili attacchi, altre estensioni del SO per confinare e tollerare processi intrusivi in esecuzione insieme a processi legittimi. Questo potrebbe permettere un analisi sicura dell attacco mentre l intrusione è in corso. Questo articolo è una versione rivista ed estesa del Bernaschi et al. [2000]. In particolare le maggiori estensioni includono: Una dettagliata analisi delle system call usate per creare, caricare e cancellare moduli caricabili del kernel; Progettazione ed implementazione a livello kernel di uno schema per prevenire e sovvertire applicazioni privilegiate dal caricare moduli kernel malevoli. Il sistema esteso mantiene una firma digitale del codice eseguibile dei moduli legali che sono gli unici a poter essere caricati ed eseguiti.

3 Un reference monitor completamente nuovo implementato come modulo kernel caricabile. In contrasto con l articolo Bernaschi et al. Che prevedeva solo una patch del kernel che richiedeva una analisi più semplice; L accesso al ACD (database control access) con l ausilio del file system virtuale standard di UNIX /proc. L amministratore di sistema vede l ACD come una directory; ogni file contiene il set di regole per una data system call. Questa nuova feature permette all amministratore di sistema di accedere all ACD attraverso l interfaccia standard del file system unix. Il resto dell articolo è organizzato nella maniera seguente. La sezione 2 descrive il risultato dell analisi che è la base fondamentale del presente lavoro. La sezione 3 passa in rassegna le idee principali dietro la nostra proposta. La sezione 4 offre dettagli sugli algoritmi e le strutture dati utilizzate nella implementazione corrente nel Linux kernel. La sezione 5 analizza degli approcci correlati presentati in letteratura. La sezione 6 conclude l articolo e discute riguardo le attività future. 2. L analisi del problema Qualsiasi sistema operativo moderno distingue tra task ordinari e privilegiati. Uno dei doveri del sistema operativo è prevenire che i task ordinari compromettano la sicurezza del sistema. Quindi il focus della nostra attenzione è sui task privilegiati che sono pericolosi se sovvertiti dato che, di default, il Sistema Operativo si fida di loro. Il lavoro presente è di natura empirica. Abbiamo analizzato il proposito e l implementazione del set completo delle system call linux, abbiamo studiato come ciascuno di essi accede alle strutture dati sensibili per la sicurezza e abbiamo classificato le system call che potrebbero essere invocate da un task privilegiato sovvertito. Abbiamo generalizzato le nostre osservazioni per essere in grado di presentare argomentazioni ed esempi per sostenere l affermazione seguente: aggiungendo dei test di controllo dell accesso a un piccolo numero di system call e monitorando un subset dei processi, la protezione contro i task privilegiati sovvertiti è completa e non può essere bypassata eseguendo system call non protette. Questo risultato riduce il costo di monitorare le system calls dato che l invocazione della maggior parte di esse non viene controllata. L analisi descritta in questa sezione si riferisce al sistema operativo Linux, comunque la maggior parte dei risultati si possono applicare ad altre versioni di UNIX. Una classe tipica di attacchi che provano a sovvertire i task privilegiati sono quelli basati su buffer overflow, descritti in breve di seguito. 2.1 L attacco buffer overflow La mancanza di controllo dei limiti degli array in C rende possibile eseguire l overflow di un buffer di memoria oltre i suoi limiti. Attraverso tecniche ampiamente note [ Aleph One 1996; Conover and the w00w00 Security Team 1999; Mudge 1996 ] un utente malintenzionato potrebbe iniettare del codice eseguibile all interno dei buffer di memoria appartenenti allo stack o al segmento dati di un processo P. In aggiunta, se l attaccante riesce a manipolare l indirizzo di ritorno di una funzione, il frammento di codice che ha iniettato è eseguito dal processo P. Ovviamente il processo P corrispondente al programma con il bug mantiene il suo status inclusi privilegi speciali (se ne ha). Di conseguenza se la tecnica è applicata con successo ad un processo privilegiato a il codice attaccante viene eseguito, per esempio, per avviare l esecuzione di una shell interattiva l attaccante ottiene l accesso ad una shell con privilegi. I componenti software di sistema, ossia, i comandi, i demoni, e le librerie scritte in C,

4 raramente eseguono tutti i dovuti controlli prima di invocare le funzioni come sprintf or strcpu che potrebbero risultare in un buffer overflow. Questa caratteristica li rende un ovvio obbiettivo degli attacchi basati su buffer overflow specialmente se questi componenti generano processi in esecuzione con privilegi di superuser. 2.2 Task privilegiati In Linux un task privilegiato potrebbe appartenere ad una delle seguenti 3 categorie: Interattivo: Qualsiasi processo avviato a mano dal superuser del sistema. Sia l identificatore dell utente (UID) che l effettivo identificatore dell utente (EUID) sono uguali a 0. Nessuna minaccia addizionale viene generata da un task simile dato che l utente che lo avvia ha già pieno controllo del sistema. Setuid: E un task che impega il meccanismo UNIX del bit setuid per dare agli utenti ordinari privilegi speciali per un tempo limitato. Per questo tipo di task la coppia di identificatori (UID,EUID) ha valori UID > 0 e EUID = 0. Quindi un task può essere identificato all interno del kernel linux come setuid a root attraverso la macro #define IS_SETUID_TO_ROOT(proc)!((proc)- >euid) &&(proc)- >uid Per sistemi operativi specifici, potrebbero essere necessarie altre informazioni per identificare un processo set- uid. Per esempio, nel SO AIX un buon candidato sembra essere l UID LOGIN che è assegnato durante l autenticazione iniziale dell utente e non viene mai modificato. La nostra scelta è motivata dalla considerazione che la coppia (UID,EUID) è presente in tutte le distribuzioni UNIX. Questo dovrebbe rendere più semplice l estensione del nostro lavoro ad altre piattaforme UNIX. Background: In genere, questo è o un processo demone avviato a tempo di avvio o un task avviato periodicamente dal demone cron per conto di root. Entrambi UID e EUID sono uguali a 0. La differenza con i task interattivi è descritta nella sottosezione Background root tasks. Su un tipico sistema UNIX ci sono sempre programmi root in esecuzione in background. La maggior parte del tempo, l amministratore di sistema non li avvia direttamente (i.e. durante una sessione interattiva) ne controlla la loro esecuzione, per cui tali programmi incustoditi sono gli obbiettivi di attacco preferiti. Secondo Stevens 1998 è possibile raggrupparli come segue: 1. I processi demoni originati direttamente dagli script di inizializzazione del sistema. I server di rete come inetd super- server, e Web Server e mail server (sendmail) sono spesso avviati in questo modo. Un altro esempio è il demone syslogd. 2. I server di rete avviati dal super server inetd per espletare le richieste di servizi come accesso remoto (telnet), file trasnfer (FTP) e cosi via. 3. I programmi eseguiti su base regolare dal demone cron. Il demone cron stesso è avviato a tempo di avvio (appartiene al gruppo 1). 4. I programmi eseguiti solo una volta nel futuro attraverso il comando at. Attualmente tali programmi possono essere considerati un caso speciale del gruppo precedente.

5 5. I programmi avviati in backround durante una sessione interattiva (i.e. con un & alla fine della command line). Questo viene fatto per la maggior parte per testare e riavviare un demone che era terminato per qualche ragione. Questi programmi non hanno un terminale di controllo. Per distinguerli dai programmi root in esecuzione in modalità interattiva ricorriamo alla macro: #define IS_A_ROOT_DAEMON(proc)!((proc)- >euid)&&((proc)- >tty==null). qui la prima clausola logica controlla che il processo sia eseguito con privilegi di root (EUID = 0) mentre la seconda controlla se il processo ha un terminale di controllo. Secondo Stevens [1998] e Comer and Stevens [1998] assumiamo che un demone non abbia mai bisogno di un terminale di controllo. Notare che: - Non c è alcuna primitiva di sistema che permette ad un task di riacquisire un terminale di controllo. Come conseguenza un demone sovvertito non può bypassare il nostro sistema di controllo provando a comportarsi come un task interattivo. - Un demone può ancora aprire un dispositivo terminale (e.g. /dev/tty o /dev/console) per loggare messaggi di errore. 2.3 Analisi delle System Call L analisi presentata in questa sezione identifica le system calls che potrebbero compromettere la sicurezza del sistema. Le system calls disponibili in Linux 2.2 sono state raggruppate in categorie in base alle loro funzionalità come riportato nella Tabella 1. In aggiunta ogni chiamata a sistema è stata classificata nella tabella II che rappresenta le caratteristiche essenziali dei quattro livelli di minaccia considerati. Per convenzione, le system calls meno pericolose corrispondono ad un numero di livello più alto. Questa classificazione corrisponde ad una gerarchia di minaccia, dato che una system call classificata con livello n potrebbe essere impiegata anche per portare un attacco ad un livello m >= n. Per esempio se una system call permette ad un attaccante di avere accesso ad una shell privilegiata, l attaccante ha pieno controllo del sistema (Minaccia di livello 1). In questo caso è facilissimo condurre un denial of service (minaccia di livello 2) e cosi via. Notare che

6 non vale l inverso. Per esempio il secondo livello di minaccia classifica le system call che potrebbero essere usate per un attacco denial of service ma ciò non da all intruso il pieno controllo del sistema (e.g. la system call reboot). La minaccia di livello 3 contiene le system call che potrebbero essere usate per sovvertire il comportamento di un singolo processo (che ha invocato la system call), ma non possono mettere direttamente a rischio la sicurezza del resto del sistema (e.g. la system call pause piò bloccare l esecuzione di un singolo processo che sta eseguendo un particolare servizio del sistema). Esiste un numero di possibili sottolivelli all interno di ogni classe definita nella tabella II. Per esempio una minaccia può essere remota o locale. Tipicamente un intruso che non ha accesso diretto al sistema può attaccare solo i task demoni, mentre un attaccante in locale potrebbe provare a dirottare anche i programmi setuid. Un altra possibile differenza è quella tra minaccia diretta ed indiretta. Un esempio di minaccia diretta è l esecuzione di una shell interattiva con privilegi di root. Una minaccia indiretta è il recupero delle password criptate che potrebbero essere usate per un attacco di dizionario offline. In questo articolo ci concentriamo sul problema presentato dalle system calls di livello I senza distinguere l origine dell attacco. L analisi e la distinzione in 4 classi di minacce potrebbe essere usata per future estensioni dato che l architettura di sistema che descriviamo nella sezione 3 non è limitata dalla scelta attuale.

7 Questi dettagli della classificazione delle system calls sono riassunti nella tabella 3 e sono brevemente discussi di seguito. Nessuna system call nei gruppi dal IV ad IX può essere usata per prendere controllo del sistema. Per esempio le system calls nel gruppo IX restituiscono immediatamente l errore ENOSYS, mentre le primitive del gruppo VIII (riservato) non possono essere invocate da un processo di un generico utente (anche se è un processo privilegiato). Le system calls che appartengono al gruppo VII (informazioni di sistema) restituiscono un set di informazioni come l host o il nome del dominio che sebbene siano importanti non permettono ad un attaccante di prendere il controllo del sistema (esse diventano critiche se vengono invece considerati gli attacchi denial of service (DOS)). Considerazioni simili si applicano alla classe V (i.e. le system calls relative alla gestione del tempo e dei timers). Le due system calls nel gruppo VI sono la base di qualsiasi comunicazione tra processi (sia locale che remota). Esse non accedono ad alcuna risorsa legata alla sicurezza. Le system calls di livello 4 (gestione della memoria) sono specialmente critiche per gli attacchi DOS (e.g. mlock disabilita il paging per alcune pagine della memoria). Comunque, dato che le risorse controllate non includono il file system o i privilegi del processo, queste primitive non sono critiche per il sistema.

8 Come per le system calls nel gruppo III (gestione dei moduli) un processo sovvertito potrebbe usarle per caricare un modulo maligno (e.g. un modulo che non è listato in /lib/modules). La nostra indagine mostra che l init_module è l unica primitiva che raggiunge il livello di minaccia 1 dato che nessun modulo può essere attivato senza aver prima invocato init_module. Il set più grande (78) di system calls è relativo alla gestione del processo (gruppo II). Tra queste primitive 10 raggiungono i livelli più alti di pericolo per la sicurezza del sistema. execve può essere usata per avviare una shell con privilegi di root. Le altre 9 primitive impostano gli identificatori per gli utenti e per i gruppi. E da notare il fatto che capset permetta ad un solo processo di restringere le sue capacità, per cui è considerata di livello 3. Le 12 system calls relative al file system (Gruppo I) classificate come livello di minaccia 1 richiedono particolare attenzione. Un intruso che ha accesso al CD- ROM connesso al sistema vittima potrebbe costruire un file system che contiene un fake /bin con dei programmi trojan horse. Quindi attraverso l invocazione di: Mount( /dev/hdb, /bin, ext2, MS_MSG_VAL,NULL) L intruso potrebbe coprire la directory /bin legittima con la sua fake directory /bin. Sebbene sia meno comune, ci sono exploits non meno dannosi di quelli basati sulla classica shellcode. E evidente che: chmod( /etc/passwd, 0666) chown( /etc/passwd,intruder,intruder_group) rename ( /tmp/passwd, /etc/passwd ) Compromette il meccanismo di autenticazione del SO. Comunque, è necessario considerare anche le catene di system calls. Per esempio, chown e chmod possono essere usate in un attacco a due assi per creare una setuid shell: chown( myshell,root,root group) chmod( myshell,4755) Mentre la sequenza unlink( /etc/passwd ) link ( /tmp/passwd, /etc/passwd )) produce gli stessi effetti della rename. Le catene di system calls viste possono essere eseguite sia in un singolo attacco o in due attacchi successivi ed indipendenti. Altre forme di catene di system calls pericolose (e.g. combinazioni di open e write) permettono la creazione di un nuovo account con UID=0 o la creazione di file.rhost fake nella home directory di root. Comunque attacchi di questo tipo devono essere condotti all interno del contesto di un singolo task sovvertito dato che la system call write ha bisogno di un file descriptor restituito dalla open. Per cui il task sovvertito invoca almeno 2 system calls: una prima per aprire il file e la seconda per modificarlo. In questo caso, in accordo con Goldberg et al.[1996] assumiamo che sia

9 necessario monitorare solo la primitiva open. Questo è il motivo per cui la system call write non è considerata una minaccia di livello 1. Ricordiamo che i controlli sono rafforzati sui programmi demoni o sui setuid solo nel caso in cui essi invocano delle system call critiche mantenendo EUID=0 (con i loro privilegi speciali), Dato che questi programmi in genere accedono ai file in scrittura con EUID uguale all owner del file, l accesso ai file utente non ha bisogno di essere autorizzato. Uno studio dettagliato dei programmi setuid e dei demoni è stato portato avanti per definire quali directory e file essi hanno bisogno di scrivere per scopi legali. Questo è stato realizzato sia ispezionando il codice sorgente che i risultati prodotti dal comando strace che intercetta e memorizza le system calls invocate da un processo. La tabella IV sintetizza i risultati dell analisi. 3. L architettura di sistema Un approccio radicale nel risolvere le questioni di sicurezza poste dai task privilegiati è controllare l esecuzione di tutte le system calls. Un astrazione largamente utilizzata per definire un tale controllo è il concetto di reference monitor descritto in Ames et al [1983]. L idea di base è che l unico percorso che i processi possono percorrere per accedere alle system calls è attraverso il reference monitor mostrato in Figura 1.

10 Il reference monitor consiste di due funzioni principali: la funzione reference e la funzione authorization. La funzione reference è usata per prendere decisioni riguardo il permettere o negare una richiesta di system call basandosi su informazioni mantenute in un access control database (ACD). Concettualmente l ACD contiene delle entries o delle regole di controllo degli accessi nella forma di un processo, di una system call o della modalità di accesso. Le regole di controllo dell accesso nell ACD catturano condizioni sia sulle system calls che sui valori dei loro parametri. Per esempio, una regola di controllo dell accesso per l execve potrebbe specificare nel campo modalità di accesso la lista dei file eseguibili che il processo chiamante può eseguire, cioè, i file che il processo chiamante può passare legalmente come parametri alla execve. Tale caratteristica previene che un processo registrato impropriamente come privilegiato possa eseguire programmi pericolosi come una shell interattiva. Da notare che i controlli sulla system call che accede al file system non sono basati semplicemente sul nome del file passato come parametro. In realtà i controlli si riferiscono alle informazioni salvate nell inode del file. Come spiegato nella sezione 4, i test basati sui nomi dei file possono essere bypassati rinominando il parametro del file. L ACD non è parte del reference monitor, ma tutte le modifiche a tale database sono controllate per mezzo del suo secondo componente, la funzione di autorizzazione. Questa funzione è utilizzata per monitorare i cambiamenti alle regole di controllo degli accessi individualmente. Uno dei principi fondamentali di un reference monitor è la sua completezza,cioè che tutti gli accessi devono essere mediati dal monitor. Sfortunatamente, l implementazione a livello di entry point della system call di questo principio ha un costo elevato che è costante indipendentemente dalla system call [Sekar et al. 1999]. Comunque, un controllo a grana fine su oltre 200 primitive costituisce un grande sforzo implementativo e di manutenzione. Abbiamo ridotto l overhead e semplificato lo sviluppo di un prototipo che si basa sulle analisi della sezione 2. Questo permette l identificazione di un subset di system calls e di un subset di tasks (i task privilegiati non interattivi) che hanno bisogno di essere monitorati per offrire una protezione completa contro gli attacchi mirati ad ottenere controllo immediato e pieno del sistema target. In altre parole, il sistema non può essere attaccato eseguendo delle system calls non protette.

11 Seguendo questo approccio abbiamo costruito un prototipo che rileva e blocca gli attacchi basati sulla sovversione di task privilegiati (e.g basati su buffer overflow) prima che essi possano essere completati. Il prototipo implementa le funzioni del reference monitor e in particolare l intercettazione delle system calls all interno del kernel del SO Linux. Per mezzo di controlli eseguiti dal kernel del SO prima che la system call sia completata è possibile prevenire qualsiasi possibile side effect delle system calls che gli intrusi sfruttano per i loro attacchi. Da notare che i controlli eseguiti all interno delle system call non richiedono cambiamenti nelle strutture e negli algoritmi del kernel esistente. Quindi tutte le modifiche al kernel restano trasparenti ai processi applicativi che continuano a funzionare senza richiedere cambiamenti del codice sorgente o ricompilazioni. 4. Implementazione Questa sezione descrive i miglioramenti al kernel linux che bloccano qualsiasi tentativo di dirottare il controllo di un processo privilegiato. In particolare questa sezione tratta il problema degli attacchi nei quali un intruso prova a prendere accesso immediato al sistema come utente privilegiato (i.e. root). In base a questa scelta, il prototipo monitora quelle system calls invocate da processi di root che potrebbero compromettere la sicurezza e l integrità del sistema operativo. Ovviamente in un sistema che mantiene informazioni sensibili per l utente, un programma sovvertito non dovrebbe mai leggere o modificare tali informazioni. La descrizione include le funzioni di autorizzazione, le strutture dati aggiunte al kernel del SO per implementare l acces control databese, la nuova system call per leggere, scrivere e aggiornare l ACD e le funzioni reference. 4.1 Le funzioni di autorizzazione L ACD contiene una sezione per ogni system call sotto il controllo del reference monitor. Per esempio, il prototipo REMUS maniente una struttura dati setuid_acd per controllare l accesso alla system call setuid e una execve_acd per controllare l accesso alla system call execve. Il layout della struttura dati execve_acd è mostrato in figura 2.

12 Questo layout è composto da due array di strutture eflst_t. admitted: Un file eseguibile F ha una entry in questa struttura se almeno un programma privilegiato ha bisogno di eseguire F attraverso una execve. L informazione memorizzata nella entry è la lista di tutti i programmi privilegiati che possono invocare F. failure: Questa lista mantiene un log degli accessi non autorizzati (i.e. non esplicitamente permessi dalla data structure admitted) ad invocare execve da qualsiasi processo privilegiato. La Figura 3 mostra la data structure admitted che è un array in cui ogni elemento si riferisce ad un file eseguibile e punta ad una lista di programmi privilegiati che possono eseguire quel file. La struttura dati failure (non mostrata in figura) è simile alla admitted, ma cresce dinamicamente con il crescere delle invocazioni fatte da programmi privilegiati non autorizzate intercettate dal kernel. Per ora è tenuta solo a scopi di revisione. Ogni elemento della struttura dati admitted contiene tre campi: efid, proc_nr e programs.

13 efid: questo campo identifica il file eseguibile F. le informazioni contenute nell efid sono: Device: il numero del dispositivo del file system a cui F appartiene; Inode: il numero dell inode del file F; Size: la dimensione di F in bytes; Modif: timestamp dell ultima modifica ad F; la coppia dispositivo e inode identifica il file F in modo univoco all interno del sistema, mentre size e modif, permettono di rilevare modifiche non autorizzate del contenuto del file. prog_nr: questo campo indica la lunghezza della lista di programmi, che è, il numero di programmi privilegiati che possono invocare il file F. programs: Questo è un puntatore alla lista dei programmi privilegiati che possono eseguire il file F. Ogni elemento chiamato suidp_id, della lista contiene 2 campi: comm e count. La stringa di caratteri comm mantiene una copia del nome del programma privilegiato come appare nel campo comm della tabella dei processi. Il campo count è usato per statistiche ed indica il numero di invocazioni del file F dal processo comm. Abbiamo introdotto una nuova system call chiamata sys_aclm, che permette l interazione con il kernel per la lettura e la modifica delle informazioni tenute nell ACD. La system call sys_aclm può essere invocata unicamente dai processi root interattivi con EUID =0 e UID = 0. Queste restrizioni sono richieste per prevenire che un demone root o un setuid sovvertiti possano corrompere l ACD. Dato che processi distinti possono accedere all ACD, possono crearsi dei conflitti. Per cui le nostre nuove primitive rafforzano un meccanismo di controllo della concorrenza tra i processi conflittuali. In particolare una variabile lock chiamata write_pid è utilizzata per implementare la mutua esclusione. Per evitare delle race conditions sulla write_pid stessa, questa variabile deve essere controllata e aggiornata atomicamente. Questo è stato raggiunto per mezzo di una funzione del kernel chiamata atomic_acces che ricorre alle istruzioni dell architettura intel per gli scambi atomici: xchg. Attualmente, la sys_aclm è un frontend comune per 5 operazioni differenti che sono brevemente descritte qui di seguito: PUT(entry, list) aggiunge una entry nella specifica list dell ACD GET(entry, list) legge una entry dalla specifica lista dell ACD. DELETE(entry, list) rimuove una entry dalla lista specifica dell ACD. Se la entry è NULL allora rimuove tutte le entry della lista. PUTHEADERACL(header- acl) memorizza l header dell ACD nello spazio di memoria del kernel. E utile quando il sistema è avviato per la prima volta dopo l installazione GETHEADERACL(local- header- acl) recupera l header del database di controllo degli accessi dallo spazio del kernel e lo memorizza nella variabile locale local- header- acl. L amministratore di sistema può gestire l ACD ricorrendo alla system call sys_aclm attraverso un nuovo comando chiamato aclmng. Per esempio il comando seguente permette al programma sendmail di scrivere qualsiasi file nella directory /var/spool/mail: aclmng v open D /var/spool/mail /usr/sbin/sendmail mentre per prevenire che un task sovvertito dal caricare un modulo parport malevolo, il modulo legale potrebbe essere signed per mezzo dell algoritmo MD5 con il comando (vedi sezione 4.2 per dettagli):

14 aclmng v init_module /lib/modules/ /parport.o Il contenuto dell ACD può essere listato per mezzo del file system /proc. C è un nodo per ogni system call e un header che da la configurazione corrente del meccanismo di controllo (ad esempio le system calls sotto controllo, i flags di debug o bloccanti). Un esempio dell output è mostrato nella figura 4. L aggiunta di un nodo al file system /proc richiede il riempimento di una struttura proc_dir_entry con i giusti valori e la chiamata a proc_register per agganciare il nuovo nodo al suo genitore nella gerarchia di /proc. Per esempio per aggiungere il nodo open: Nel prototipo attuale le entry dell ACD non possono essere modificare attraverso l interfaccia /proc. Uno dei possibili miglioramenti a cui stiamo pensando è permettere la configurazione dell ACD e l attivazione del meccanismo di controllo per mezzo del comando standard sysctl. Questo richiede l aggiunta a /proc/sys di un nodo acd e sottonodi /proc/sys/acd per tutte le system calls sotto controllo. In questo modo potremmo disfarci del metodo aclmng. 4.2 Le funzioni Reference Questa sezione presenta alcuni esempi delle estensioni introdotte per controllare le system calls con livello di minaccia 1 definite nella sezione 2.3. execve. Come mostrato nella figura 5 la reference function viene invocata all inizio di questa sistem call dopo che il file è stato aperto. La funzione check_rootproc() che riportiamo in appendice autentica il processo root che invoca execve e controlla nel database di controllo degli accessi se il processo chiamante ha il diritto di eseguire il programma il cui nome viene

15 passato come primo parametro. L esecuzione della system call è negata quando il check_rootproc restituisce uno di questi 2 valori: EXENA: Il processo chiamante non ha l autorizzazione ad eseguire il programma richiesto. Cioè il nome del programma non è presente nel database del controllo degli accessi o il programma chiamante non è listato nel campo programmi della lista admitted nel database di controllo degli accessi. EFNA: Il processo chiamante è autorizzato ad eseguire il programma richiesto ma il file non è autenticato. Per esempio, il tempo di modifica o la dimensione non matchano. Nella funzione check_rootproc se il processo chiamante non esegue con privilegi di root (EUID = 0) non viene eseguito alcun altro controllo e la execve procede normalmente. Altrimenti il servizio è offerto se e solo se il permesso è esplicitamente contenuto nel database di controllo degli accessi. La figura 5 si riferisce alla versione di remus nella quale l intercettazione è condotta all interno del codice della system call. Attualmente, c è un altra versione di REMUS che sovrascrive la tabella delle system calls ed esegue il redirect dell esecuzione a delle routines che chiamiamo REMUS wrappers. Ogni wrapper include i controlli di sicurezza richiesti per la system call corrispondente. Se il risultato dei controlli è positivo la system call reale viene invocata, altrimenti l esecuzione è negata dando gli stessi errori della versione patchata. Sebbene la patch richieda una limitata modifica del codice del kernel originale, ci sono un numero di vantaggi rispetto a questo secondo meccanismo di intercettazione.

16 L overhead dell intercettazione potrebbe essere ridotto al minimo dato che non c è alcun livello di astrazione addizionale. La maggior parte delle informazioni richieste dal meccanismo di controllo è disponibile e può essere usata senza bisogno di duplicarla. Per esempio, il numero di inode del file che il sistema dovrebbbe exec è determinato dalla funzione open_namei una sola volta. Non c è modo di bypassare il meccanismo di controllo dato che è parte del percorso di esecuzione delle system call. Il principale inconveniente della versione patchata è la mancanza di portabilità e modularità. I controlli di sicurezza sono sparsi nel codice delle System calls. Di conseguenza portare Remus su versioni nuove del Linux Kernel richiede più attenzione. setuid. Per la system call setuid, l autenticazione dei processi root è la stessa del caso execve. Un utente che esegue un programma setuid che tenta di invocare setuid(0) per assegnare UID = 0 a se stesso è obbligata a scrivere la password di root. La password immessa viene comparata ad una copia criptata tenuta nel database di controllo degli accessi. Nel caso la password immessa sia errata, la chiamata setuid(0) è negata. Un esempio di un programma che è controllato con questo meccanismo è su, un programma setuid che esegue una shell con l ID (e il gruppo) di un altro utente. Le altre system calls che gestiscono gli identificatori di utenti e gruppi sono controllate nello stesso modo. chmod. Un controllo aggiuntivo è eseguito sul parametro filename se chmod è invocata da un processo di tipo setuid o background. Questo significa che l operazione è permessa se filename si riferisce ad un dispositivo registrato nell ACD. I programmi importanti come X server (che è un processo di tipo background con privilegi di root) non funzionerebbe senza questa distinzione. Queste considerazioni si applicano anche a fchmod, fchown, chown e lchown. open. Alcuni programmi setuid o demoni con privilegi di root per buone ragioni potrebbero aprire file critici. Il prototipo presente monitora solo gli accessi ai file in scrittura. Capiamo che potrebbe essere possibile rubare dati sensibili come password criptate o i nomi degli host trusted, ma attacchi di questo tipo vanno aldilà dello scopo di questo lavoro. Alcune volte potrebbe essere necessario lasciare che i programmi di root scrivano qualsiasi file in directory specifiche definite nell ACD. Questo è il caso di directory come /var/mail o /var/spool/mqueue usato da sendmail. Per directory come /etc è invece richiesto un controllo a grana fine. Quindi un file foo appartenente ad etc potrebbe essere modificato da un programma prog solo se prog e gli identificativi (inode e device number) di foo sono esplicitamente inseriti nell ACD. init_module. Il caricamento di moduli kernel in Linux è una procedura a due passi: la system call create_module riserva memoria per il modulo mymodule e ini_module lo carica in memoria e chiama l entry point di inizializzazione di mymodule. E necessario prevenire che un task sovvertito carichi un modulo malevolo(ad esempio un modulo che cambia i permessi di /etc/passwd). Potremmo assumere che i moduli trovati in directory ben note come /lib/modules siano legali. Sfortunatamente non c è modo per l init_module di conoscere l origine del modulo. Per risolvere questa questione una signature dei contenuti di ogni modulo legale è memorizzata nell ACD.All interno di init_module la signature di mymodule passato come parametro viene calcolata. Se non c è alcuna signature per mymodule nell ACD o c è un mancato match tra le due signatures init_module fallisce e mymodule non viene caricato nel kernel. Una tecnica largamente diffusa per definire la signature di un blocco dati è calcolare il suo checksum attraverso l algoritmo MD5. Questo approccio non può essere applicato in modo

17 semplice al file oggetto che contiene il modulo perché alcune parti di esso cambiano a causa della rilocazione dell indirizzo ( un passo della procedura di caricamento richiesto per il linking dinamico di un modulo o di un file eseguibile con librerie condivise). Una soluzione possibile è saltare le entry rilocabili quando l algoritmo md5 viene applicato alla sezione text del file oggetto del modulo. La posizione delle entries che devono essere rilocate è parte delle informazioni incluse nell header di ogni sezione di un file oggetto compliant con il formato degli eseguibili e dei linkabili (ELF, standard object format in Linux). Dato che gli headers ELF non sono disponibili all interno dell init_module è necessario mantenere la posizione delle entries rilocabili nell ACD. Fortunatamente il numero di tali entries è tale che la dimensione dell ACD non incrementi troppo. In aggiunta alle system calls definite nella sezione 2.3 come livello di minaccia 1, due system calls sono controllate da remus: sys_aclm e delete_module. Un attaccante potrebbe usare sys_aclm per rimuovere una regola di controllo degli accessi dall ACD e usare delete_module per rimuovere il modulo kernel che implementa lo stesso REMUS. Per queste ragioni ci sono delle entry nell ACD per queste due primitive tali che sys_aclm e delete_module (per il modulo remus) non possono essere invocate da nessun task setuid o demone con privilegi di root. 4.3 La struttura del codice del prototipo Il software del prototipo è disponibile da ftp://ftp.iac.rm.cnr.it/pub/remus ed è composto di alcune parti: Un modulo caricabile contentente le strutture ACD, la system call sys_aclm e l interfaccia /proc. Un piccolo set di kernel patches. Esse implementano il meccanismo di intercettazione e consistono di nuovi frammenti di codice aggiunti alle system calls esistenti (non ci sono ne cambiamenti ne cancellazioni). Sebbene le patch siano state sviluppate e testate su una versione specifica del kernel linux, non ci aspettiamo problemi rilevanti nel portarle a versioni nuove del kernel. Il nuovo comando aclmng (descritto nella sezione 4.1) I doveri di amministratore del sistema sono limitati a riempire l ACD eseguendo il comando aclmng. La ricompilazione delle applicazioni esistenti o di altri componenti del software non è necessaria. Notare che riempiendo l ACD su grandi installazioni di sistemi omogenei è semplice dato che la maggior parte delle regole contenute nell ACD possono essere riutilizzate senza cambiamenti. Nel caso in cui l esecuzione di una system call sia negata dal sistema di controllo un messaggio viene inviato buffer dell anello kernel. In tale modo, l amministratore può controllare la presenza di potenziali attacchi guardando ai messaggi che iniziano con il prefisso REMUS. 4.4 Prestazioni Ci aspettiamo un degrado davvero limitato delle performance globali del sistema che esegue il nostro kernel migliorato. Ci sono un numero di ragioni per questa previsione. Quando un processo esegue in modalità user, non c è alcuna differenza dal sistema standard dato che tutti i nuovi controlli sono eseguiti in kernel mode.

18 Quando un processo esegue in kernel mode, solo un subset limitato di processi esegue tutti i controlli. Un generico processo utente che invoca una system call con livello di minaccia 1 subisce solo i seguenti controlli all interno delle system call equipaggiate: if(is_setuid_to_root(current) IS_A_ROOT_DAEMON(current) ) { } quindi se il processo non è ne un demone con privilegi di root ne un setuid a root, non esegue più di un paio di test logici (notare che le due condizioni sono valutate separatamente semplicemente per una sana lettura del codice). Solo poche system calls includono controlli aggiuntivi (solo il 10% del numero totale delle system calls). Ad eccezione della primitiva open, è raro che un processo demone o un setuid invochino alcune delle system call equipaggiate più di una volta durante il suo tempo di vita. I controlli non richiedono alcun accesso a dati out of core. Tutte le informazioni sono residenti nella memoria kernel. Per supportare queste considerazioni sono stati eseguiti un set di esperimenti. Abbiamo scelto 4 applicazioni e le abbiamo eseguite sullo stesso sistema hardware (pentium II 330Mhz con 128 Mb di RAM) prima con un Linux kernel standard in versione e poi con il kernel patchato con REMUS. Le seguenti 4 applicazioni sono state misurate: sendmail, lpr, rsync e X server. Il risultato degli esperimenti, riportato in dettaglio in Bernaschi et Al [2000] rivela che la differenza tra i tempi medi di esecuzione delle applicazioni è comparabile con la deviazione standard di esecuzioni multiple. Questo suggerisce che l attuale impatto di REMUS sulle performance globali del sistema non è rilevante per utilizzi tipici. Abbiamo anche condotto ulteriori esperimenti con lo scopo di valutare persino il minimo overhead dovuto alla funzione reference eseguita da REMUS. Gli esperimenti si focalizzano sulla singola invocazione di una system call critica e l evaluation delle regole di controllo degli accessi nell ACD. Da notare che, nel prototipo REMUS basato su modulo, la system call che richiede il più alto overhead di monitoraggio è la open. Infatti, l invocazione di open richiede una doppia risoluzione dei nomi dei percorsi, cioè, due invocazioni della routine namei. Per prima namei è invocato nel modulo di sicurezza per trovare il numero di inode e altre informazioni del file necessarie ad applicare le regole di controllo degli accessi nell ACD. Poi se la comparazione ha successo è richiesta una seconda risoluzione del pathname è eseguita nel codice nativo

19 standard della system call non modificata. In aggiunta nel prototipo basato su patch di REMUS tutte le system calls hanno un overhead di monitoraggio comparabile. In particolare, l invocazione di open richiede solo una singola risoluzione standard del pathname. Infatti le informazioni del file necessarie per il controllo vengono determinate durante l esecuzione del codice standard della system call. L esecuzione è intercettata prima che il file corrente sia aperto e le informazioni del file disponibili vengono usate direttamente per la verifica nell ACD. Dunque, nel sistema basato su patch l overhead di monitoraggio delle system call critiche è limitato. Per supportare queste affermazioni abbiamo condotto alcuni microbenchmarks per le system calls open nei tre sistemi: standard Linux, patched based remus, e module based remus. Notare che il linux kernel mantiene una cache per la traduzione di un pathname in un inode. Questa cache viene acceduta da namei ed è chiamata dirent cache o directory entry cache. Come primo esperimento per ottenere una misurazione più precisa del tempo di esecuzione di open, tale cache è stata disabilitata. E stato utilizzato (150 Mhz Intel pentium con 32 Mb di RAM) un hardware più lento per incrementare il valore assoluto delle misurazioni prese in microsecondi leggendo il clock register del microprocessore in tempo reale prima e dopo l esecuzione. La prima colonna riporta che la lunghezza del percorso passato come parametro ad open. Notare che il tempo di esecuzione decrementa linearmente con la lunghezza del percorso nei tre sistemi. Le misurazioni relative alla Remus basata su modulo riportata nella tabella V rappresentano un upper bound dell effettivo tempo di esecuzione. Infatti la seconda invocazione di namei nella implementazione basata su modulo, ha sempre un costo computazionale minore, dato che la directory entry cache contiene sempre la traduzione del pathname all interno dell inode rilevante che è caricato durante la prima invocazione. Nella tabella V la funzione di caching è stata disabilitata ed entrambe le invocazioni consecutive di namei pagano il costo massimo. Questa situazione accadrà difficilmente nella pratica. Allo scopo di avere una valutazione migliore dell impatto del caching sul tempo di esecuzione di open abbiamo misurato il tempo di esecuzione di namei nel linux standard in funzione della lunghezza del percorso. La seconda e la terza colonna della tabella VI riportano le misurazioni con la cache abilitata e non abilitata rispettivamente. Basandoci su queste misure il tempo di esecuzione di open nella versione basata su Modulo di REMUS può essere approssimata con la formula: Topen <= modulebasedopen(nocache) namei(nocache) + namei(cache) In cui modulebasedopen(nocache) indica il costo della open riportato nella tabella V per Remus basato su modulo. Questa formula considera sempre che la risoluzione del secondo

20 pathname avvenga con la cache. La quarta colonna della tabella VI riporta i valori della formula appena vista per differenti lunghezze di paths. Notare che l effetto della cache mitiga il costo di eseguire la risoluzione del pathname 2 volte. Se definiamo l overhead di monitoraggio come il rapporto tra tempo di esecuzione della fopen in Remus rispetto al tempo di esecuzione nel linux kernel standard possiamo concludere che l overhead del Remus basato su patch è del 3% mentre in quella basata su modulo è del 18% rispetto al costo totale della open. 5. Opere correlate Altri gruppi nel passato hanno proposto la risoluzione delle problematiche di sicurezza attraverso controlli speciali dei valori dei parametri delle system calls. In Goldberg et al. [1996] è descritto un meccanismo di tracciatura user- level per restringere l ambiente di esecuzione di applicazioni helper non attendibili. La nostra soluzione è basata su un analisi simile dei potenziali problemi associati con un subset delle primitive di sistema, ma noi controlliamo un set differente di programmi (i.e. root daemons e programmi setuid invece di applicazioni helper). Noi aggiungiamo dei controlli addizionali al codice delle system call principalmente per ragioni di performance ma l impatto sul codice kernel esistente è ridotto allo stretto necessario. Il rafforzamento del dominio e della tipizzazione (DTE Domain Type enforchement) è una tecnlologia di controllo dell accesso che associa ad un dominio con ciascun processo in esecuzione e un tipo per ogni oggetto (e.g. file, pacchetti di rete). A tempo di esecuzione un sottosistema DTE a livello kernel compara il dominio di un processo con il tipo di ciascun file o il dominio di ciascun processo che tenta di accedere. Il sottosistema DTE nega il tentativo se il dominio del processo non possiede il diritto per la modalità di accesso richiesta per quel tipo. DTE è un approccio molto generale al controllo degli accessi obbligatori; comunque potrebbe richiedere modifiche al kernel molto profonde ( linee di codice kernel e 20 nuove system calls per le applicazioni DTE- aware). Alcuni prototipi di tale architettura sono stati proposti in passato. Per esempio DTMach e DTOS [Fine and Minear 1993; Minear 1995]. Basati entrambi sul microkernel Mach e Flask è basato suk sistema operativo Fluke sviluppato dall università dello Utah. Un gruppo sponsorizzato dalla NSA stà attualmente integrando l architettura Flask all interno di linux. Essi hanno annunciato la disponibilità di un prototipo chiamato SELinux (security enhaced Linux). Questa implementazione di linux è attualmente di una combinazione di Type Enforcement (TE), role based access control (RBAC) e sicurezza multilivello opzionale (MLS). L obbiettivo principale di SELinux è offrire flessibilità nell accesso e l etichettatura delle decisioni. La compatibilità dei binari è offerta alle applicazioni esistenti ma sono comunque richiesti cambiamenti alle strutture dati del kernel (per l etichettatura) e l estensione delle API per supportare applicazioni security- aware. Di conseguenza, SELinux è utile come sistema di test per valutare possibili aggiunte o miglioramenti al kernel Linux, ma l adozione sembra difficoltosa, nella sua forma attuale, alla community Linux. Un approccio totalmente differente è usato nel prototipo LOMAC [Fraser 2000], in questo caso l idea è di minimizzare il costo totale di compatibilità e offrire ancora benefici per la protezione. L architettura è basata sulla combinazione di un modulo kernel caricabile e l interposizione all interfaccia delle system call per modificare il comportamento del sistema operativo. Da questo punti di vista è molto simile a REMUS. Comunque il modello di sicurezza è completamente differente. REMUS permette o nega l esecuzione di system calls critiche guardando al contenuto dell ACD. Lomac definisce invece il concetto di subject (entità attive