Considerazioni finali

Nel dibattito tenutosi durante l’evento siamo arrivati alle seguenti conclusioni:
SELinux e GrSecurity, seppur con sintassi e ideologia differenti, permettono una gestione dei permessi concessi nelle policy molto più capillare.
Abbiamo valutato che SELinux, Tomoyo ed AppArmor possono essere facilmente rimossi andando a modificare un parametro di avvio del kernel attraverso il Grub; esiste una soluzione a questo problema compilando il kernel in modo che questo non possa avvenire. GrSecurity usa un approccio totalmente differente in quanto esso si fonde con il kernel. Inoltre la modifica del sistema di Hardening utilizzato è strettamente collegato all’account di root (il quale unico a poter accedere alla policy).
Se un attaccante riuscisse ad accedere allo spazio utente di root (applicando alcuni attacchi visti durante le mini-challenge per scoprirne la password), esso sarebbe in grado quantomeno di leggere le policy e, di conseguenza, adattare gli attacchi affinchè essi riescano comunque ad andare a buon fine. Questo non è vero per GrSecurity in quanto per la gestione della policy è associata una password scollegata da quella di root; pertanto l’attacco richiederebbe sia la password di root che quella delle policy.
Una buona misura di sicurezza sarebbe quella di far coesistere un sistema di Hardening proposto con una cifratura del disco in quanto nel caso di riambientazione ognuno dei tools può essere aggirato.

SELinux:
 Pro:
- Risoluzione di tutti gli attacchi, compresa la seconda variante del trojan;
- Possibilità di applicare un confine ad una categoria di utenti scrivendo la policy una sola volta per tutti;
- Raggiungere un livello di granularità tale che si può stabilire il comportamento di un software solo per una categoria di utenti;
- Per merito del default domain transition i processi runnati a cascata a partire da un processo padre, preserveranno il domain di quest'ultimo. Questo, quindi, non consente ad un utente di acquisire maggiori privilegi, sebbene questo comportamento possa essere ridefinito;
- L'aggiunta nella policy di regole di allow è molto semplice grazie all'architettura modulare di questa. Vedasi il tool audit2allow;
- La community di SELinux è molto ampia ed esiste molta documentazione ed un'intera policy pronta all'uso.

 Contro:
- Se è vero che l'aggiunta di regole di allow è molto semplice, non si può dire lo stesso per la rimozione di regole. Questo perché la policy è molto ampia ed il inoltre la sintassi, molto simile ad un linguaggio di programmazione imperativo, presenta interfacce che possono essere richiamate da ogni modulo e quindi rendere molto lunga la fase di debugging per scoprire dove si trovano le regole incriminate;
- Se è vero che si può raggiungere un grande livello di granularità, il fatto di dover generare da zero una policy per una categoria di utenti è un processo lungo che richiede una profonda fase di debugging.

AppArmor:
  Pro:
- Rispetto a SELinux e GrSecurity, consente una comprensione più agevolata dei file di policy, essendo ogni file (profilo) relativo ad un solo applicativo specifico.
- Sintassi UNIX-like delle regole, semplice ed immediata.
- Possibilità di definire sotto-profili e rispettive transizioni.
- Possibilità di usare wildcard per concedere/negare più azioni con una sola regola.

 Contro:
- Controllo effettuato sui pathname: Se ad un applicativo è negato l’accesso ad un file, è possibile bypassare la policy creando un hard-link del file in un percorso dove l’applicativo è abilitato ad accedere. Per tale ragione è necessario curare con attenzione le regole di profili e sotto-profili affinché l’operazione di linking venga concessa con parsimonia
- Contrariamente ad approcci più restrittivi adottati dagli altri sistemi, con AppArmor se un applicativo non ha un’apposita policy caricata nel kernel, verrà eseguito senza essere confinato in alcun modo da AppArmor, tornando di fatti al limitato modello discrezionale del controllo degli accessi (DAC).
- Mancanza policy di sistema: Ciò rende AppArmor poco versatile per la difesa da eseguibili malevoli, in quanto creare un profilo per uno script malevolo è realisticamente poco sensato. Questo tipo di applicativi possono essere confinati solo se le funzioni, utilizzate per fini malevoli, a sua volta sono confinate da un profilo appositamente creato; tuttavia, come è emerso dall’analisi del trojan v2, ciò può comportare policy troppo restrittive per funzioni usate dall’intero sistema.
- Policy meno granulari rispetto agli altri sistemi: Come è emerso durante il tentativo di limitare chmod, altri sistemi come ad esempio TOMOYO, permettono una granularità più fine sul tipo di maschera utilizzabile da chmod, cosa che con AppArmor non è fattibile in quanto può inibire macroscopicamente l’intera operazione di scrittura su determinati percorsi, senza distinguere la maschera utilizzata.
- Mancanza di ruoli: E’ possibile far funzionare AppArmor in sintonia con PAM (Pluggable Authentication Modules) affinchè supporti una logica basata sui ruoli, tuttavia quest’ultima è implementata da PAM e non direttamente da AppArmor, motivo per cui possiamo concludere che AppArmor non gestisce nativamente i ruoli se non appoggiandosi ad altri moduli.
- Rimovibilità: Avendo accesso fisico alla macchina, è sufficiente cambiare un file di configurazione del grub, specificando, con il flag “apparmor=0”, di non caricare l’intero modulo AppArmor all’avvio.

Tomoyo Linux:
 Pro:
- Ha una sintassi semplice e quindi le policy sono leggibili.
- La creazione delle policy da zero è facilitata grazie alla fase di Learning Mode
- Può essere usato come tool per l’analisi del sistema operativo in quanto si riesce a vedere ogni processo cosa va a richiamare ed utilizzare per funzionare

 Contro:
- Non possiede Multi Level Security
- Non implementa il RBAC
- Risiede ed agisce solo a livello namespace, a differenza degli altri tool che agiscono a livello inode e possono utilizzare più informazioni.

GrSecurity:
  Pro:
- Teoricamente compatibile con qualsiasi distro Linux;
- Può coesistere con gli altri LSM-tools;
- Buona gestione dei ruoli;
- Le regole si posson ereditare facilmente;
- Le policy possono esser create con la learning-mode;
- Fornisce la protezione della memoria.

Contro:
- Tutte le policy si trovano in un unico file;
- Non esiste un tool per scrivere le policy;
- Da Aprile 2017 è diventato a pagamento.