Marco Pizzoli SE
From ImoLUGPedia
Contents |
Autore:
Marco Pizzoli
Breve CV Relatore:
Dott. Marco Pizzoli - Laureato in Informatica Consulente informatico e Sistemista Unix/Linux, specializzato in reti e sicurezza. Si occupa di amministrazione sistemi web, ldap, database e posta.
LD11
Titolo:
...e SELinux fosse più sicuro?
Abstract intervento:
SELinux è il framework di sicurezza più famoso presente nel kernel Linux ormai da più di dieci anni. è pero' ancora sconosciuto ai più e spesso viene additato come la causa dei non funzionamenti dei servizi di sistema. Con questo intervento cerchero' di rompere il muro di diffidenza che tiene alla lontana da questa potente tecnologia, cerchero' di presentare il contesto di riferimento, i principi ispiratori, la sua storia e presentare infine il trend recente che vede alcuni servizi esterni al kernel appoggiarsi comunque al framework SELinux.
Livello
Livello Avanzato
Download
PDF 1810536 bytes
md5 93f7c47b9b4625782f2142e9ad48ae02
sha1 2231e8ed09ca18b6cf2e55be256bcee517d2ef4d
Gallery
 |
 |
 |
 |
 |
 |
Video
Follow-up
In questa sezione riportiamo una discussione tra Daniele Tampieri (DT) e Marco Pizzoli (MP) avvenuta via e-mail in seguito alla conferenza, dal 30/10/2011 allo 03/11/2011.
- DT:-"Ciao Marco, mi dispiace di essere dovuto scappare prima della fine della tua conferenza e della discussione finale. Ho però una domanda che vorrei farti sulle policy di SELinux: visto che supporta varie policy, sarebbe possibile, almeno in linea di principio, un azienda possa decidere di installare il pacchetto su tutte le sue macchine Linux per avere un controllo fine sull'impiego delle macchine in ambito lavorativo, dettagliando una propria policy?".
- MP:-"Ciao, non me la sono presa, tranquillo :-)
- La tua domanda potrebbe essere ambigua. Provo a buttare giu' diverse considerazioni e poi tu mi dici esattamente cos'e' che ti interessa principalmente.
- "Avere il controllo" puo' intendersi come auditing oppure (nella semantica anglosassone) anche il comandare.
- Se tu intendi fare auditing, SELinux non e' lo strumento su cui puntare, quanto piuttosto "auditd". Combinato con audisp ti consente di inviare tutti i log di tuo interesse a syslog e poi ci fai quello che vuoi.
- L'audit daemon ti consente di definire un "listener" su un determinato evento che avviene (a livello kernel) su un determinato oggetto:
- es. una "read" su un determinato file.
- SELinux si occupa di controllo accessi. Prende *solo* decisioni su se un determinato accesso (es. la lettura di un file) puo' essere compiuto oppure no ed ha il vantaggio di riuscire ad agire ad un livello molto capillare, oltre che ad andare ad agire anche su quanto gia' in essere: es. nel mondo DAC una volta che hai fatto una open() e ti viene ritornato un descrittore, te ne freghi di quello che avviene sui permessi del file (compreso se il file viene rimosso!). In SELinux invece il controllo accessi avviene per ogni singola read() e di conseguenza puoi interrompere qualcosa di attivo in quel momento.
- La scelta di adottare SELinux potrebbe essere un salto troppo grosso (investimento di tempo/soldi, complessita' dell'ambiente rispetto alla formazione degli operatori/lavoratori, ecc...) per lo scopo che ci si prefigge, quindi occorre pensare bene a (fino a) cosa si vuole ottenere. Personalmente vedo SELinux come uno strumento utile per arrivare la' dove altri strumenti semplicemente non possono arrivare, ma a condizione che siano gia' hardenizzati gli altri livelli prima di arrivare a SELinux: il concetto della defense-in-depth.
- Una condizione importante, a mio avviso, e' che il sistema (di persone) nel quale viene eventualmente inserito SELinux sia "pronto" per accogliere uno strumento cosi'... Il piu' grande buco di sicurezza e' quello che sta tra il computer e la sedia :-)
- Scherzi a parte, il rischio che uno poi decida (faccia pressioni psicologiche) per disattivarlo al boot e' da tenere in considerazione...
- Venendo alla tua richiesta specifica. A livello teorico ha sempre senso mettere in campo tutte le attivita' tali da ridurre la posibilita' di una violazione di accessi alle risorse. L'investimento in un SELinux che usa una policy personalizzata potrebbe non essere cosi' "a costo zero"... quindi prima di tutto occorre farsi 2 domande:
- l'analisi del rischio come valuta il danno provocato da uso illecito di strumenti informatici?
- il modo di lavorare all'interno della mia azienda (l'insieme dei processi aziendali) e' riconducibile ad un modello dal quale ricavare le regole SELinux da inserire nella mia policy?
- Ho buttato diverse considerazioni. Dimmi te se ho risposto alla tua domanda e, se no, dammi qualche elemento in piu' :-)".
- DT:-"Buongiorno Marco,
- scusa se ti rispondo con un notevole ritardo:la mia domanda era intesa a verificare la possibilità del controllo dell'accesso a certe risorse (tra i quali i file, intesi nella maniera ampia 'Unix/Linux Docet' sia come file dati che come eseguibili, che come risorse del sistema), e tu hai risposto in maniera piuttosto completa (così credo): occorre valutare i costi di una operazione di questo tipo, e forse anche gli obiettivi di una operazione simile. La motivazione alla base della mia domanda era che è molto più efficace fornire strumenti di lavoro che siano ottimi ed efficienti nel permetterti di eseguire i tuoi compiti ma completamente inutili come passatempo, piuttosto che minacciare ritorsioni basate sull'analisi dei log. Un'ultima cosa: hai nulla in contrario se aggiungo questa conversazione come follow-up alla pagina wiki del LUG con il testo e il video della tua conferenza?
- MT:-"Ciao,
- nessun problema per pubblicare questa conversazione.
- La tua considerazione e' giusta, ma apre la strada ad altri strumenti che esistono e che assicurano quella che viene chiamata "data loss prevention".
- SELinux potrebbe essere una delle tecnologie sfruttate "dietro le quinte" per offrire questo servizio.
- Sicuramente io non riuscirei ad essere esaustivo, cmq ti suggerisco di fare una ricerca sulla rete per capire cosa gli strumenti di DLP consentono di fare... sono molto interessanti!
- Come corollario... lo sapevi che VMware prossimamente fara' uscire un hypervisor *per smartphone* che, tra le altre cose, va a consentire di usare due istanze di un sistema operativo sullo stesso smartphone apposta per averne (ad esempio) uno aziendale ed uno personale, con ovviamente rubriche, accessi vpn, ecc... separati.
- Quello che una volta era definito "il perimetro" ormai e' diventato un concetto molto fumoso....
- Di scenari possibili ne abbiamo tanti sia nel presente che all'orizzonte e chi si occupa di sicurezza avra' le sue belle gatte da pelare :-)"
