Protezione dei files con SE-Linux

Un sistema ad accesso mandatorio, quale SE-Linux, permette di proteggere in maniera esaustiva un computer contenente files e dati sensibili. La sua gestione è però molto onerosa in quanto è necessario possedere delle solide conoscenze non solo dell’ambiente Linux, ma anche di sicurezza, sistemi mandatori e come funziona al suo interno SE-Linux. Spesso però da un lato non si necessita di tanta sicurezza, dall’altro non si dispone di sufficiente personale altamente specializzato per riuscire a gestire sistemi con dati sensibili. Questo whitepaper, basato su un caso reale, vuole illustrare una metodologia che coniuga alta sicurezza con una gestione di un ambiente unix non differente da quella tradizionale. Il documento si rivolge agli amministratori di sistema che abbiano solide basi di Linux e di sicurezza informatica, con una conoscenza di base di SE-Linux.

Introduzione

Mi chiedono spesso se sia possibile utilizzare SE-Linux per proteggere certe aree del filesystem o per proteggere determinate applicazioni, assimilando SE-Linux ad una specie di “firewall applicativo”. Sento spesso usare il termine “firewall applicativo” parlando di SE-Linux, ed alcune volte ammetto di averlo fatto anch’io, anche se si tratta di un concetto sbagliato. Faccio un passo indietro, facendo un breve riassunto di SE-Linux. Security Enhanced Linux, o per brevità SE-Linux, è un set di patches del kernel di Linux sviluppate dalla US National Security Agency (NSA) per portare un sistema ad accesso mandatorio (Mandatory Access Control, MAC) in ambiente Linux, similmente ad altre piattaforme unix quali Trusted Solaris. SE-Linux si appoggia alla modularità di sicurezza del kernel Linux chiamata Linux Security Modules (LSM), così come si appoggiano altri sistemi di sicurezza quale ad esempio AppArmor.

Non mi soffermerò a parlare della storia di SE-Linux, ma vorrei presentarvi un caso concreto di un cliente che possa essere facilmente riadattato per quei sistemi che debbano ospitare files sensibili. Nel caso in questione, l’obiettivo è di proteggere alcuni files in formato PDF estremamente sensibili a cui un’applicazione web-based deve accedere, ma a cui i sistemisti di gestione non possono in alcun modo accedere. L’applicazione risiede in un cluster in bilanciamento a tre nodi e i files acceduti tramite GFS, il filesystem clustered presente nella distribuzione Red Hat Enterprise Linux (vedere l’architettura in figura 1). In molti dei casi basta applicare una buona protezione usando le metodologie DAC, ovvero permessi a filesystems e Posix ACL, ma in questo caso era necessario essere sicuri delle protezioni ed era necessario effettuare log di accesso.

Nota Bene. Non siamo entrati nel merito della protezione del PDF in se stesso. In realtà in una buona filosofia “Defense in Depth” sarebbe opportuno proteggere ogni singolo layer e non solo il sistema operativo. Se per caso riescono a trovare una falla applicativa e riescono a scaricare il PDF, esso risulterebbe in chiaro. Le ipotesi sarebbero o criptare con una random password il PDF (e comunicarlo al destinatario in maniera sicura) oppure utilizzare l’infrastruttura di protezione con certificati digitali.

I requisiti che il cliente mi ha dato e alcuni aggiunti da me che io stesso mi sono voluto imporre erano:

• Univoca identificazione degli utenti (accesso LDAP)
• I log relativi a audit/sicurezza vanno inviati ad un syslog centralizzato
• Le utenze di gestione non possono diventare root, ma devono eseguire i soltanto alcuni comandi tramite il programma “sudo”
• Le utenze di gestione devono avere diversi privilegi di accesso, da operatore a system administrator autorizzato
• Gli utenti non possono fare “su -” per accedere all’utenza root anche se conoscono la password, tranne quelli esplicitamente autorizzati
• Nessun utente, tranne root e l’utente applicativo appserv possono accedere alla directory “/documents/” e relativi documenti/subdirectories
  • L’utente root ha diritto di accedere alla directory, ma le operazioni di lettura devono essere sottoposte ad audit
  • L’utente applicativo non deve essere sottoposto ad audit per la salvaguardia delle performance dell’applicazione.
  • Con l’utente applicativo appserv verrà eseguito l’application server e verranno eseguiti alcuni batch che hanno diritto all’accesso alla directory