TL; DR: sentiti libero di saltare direttamente alla conclusione in fondo se ti piace :)!
L'obiettivo di SELinux è prevenire l'escalation dei privilegi applicando una politica obbligatoria che limita le possibili azioni da parte di utenti non privilegiati e privilegiati.
Il termine "utenti" qui include anche qualsiasi processo in esecuzione sul dispositivo, indipendentemente dal fatto che sia direttamente correlato alle azioni fisiche dell'utente (l'uomo, tu;)), poiché ogni processo è in esecuzione utilizzando un account "utente" di sistema.
Storicamente, le autorizzazioni sui sistemi basati su Unix sono gestite usando quello che viene chiamato un sistema di controllo di accesso discrezionale. In questo modello:
- Risorse come i file hanno proprietari che possono definire i diritti di accesso alle risorse che possiedono: questo consente loro di decidere se una determinata risorsa deve essere privata (solo il proprietario può accedervi) o se deve essere condivisa con altri utenti.
- Inoltre, hai il superutente (chiamato
root
su sistemi basati su Unix) che è l'utente amministrativo e ha accesso a tutto il sistema. Questo account può essere utilizzato in modo interattivo da un essere umano (in genere un amministratore di sistema) per mantenere o riparare il dispositivo, ma di solito questo account verrà utilizzato principalmente da servizi in background o di basso livello che richiedono tale livello di privilegi: driver di dispositivo, servizi di configurazione della rete, servizi necessità di accedere ai file da tutti gli utenti o di gestire la comunicazione interna tra utenti.
Questo è molto bello e offre già una buona sicurezza. Tuttavia, che dire di circostanze come queste:
- Cosa succederebbe se
root
si riscontra un bug in un servizio in esecuzione, che consentirebbe a un utente malintenzionato di indurre tale servizio a eseguire codice arbitrario? Tale aggressore otterrebbe un accesso completo al dispositivo. Per fornire alcuni esempi concreti, tale errore potrebbe essere attivato inviando al telefono informazioni di configurazione di rete ( DHCP ) appositamente predisposte o un MMS .
- Cosa accadrebbe se un utente non proteggesse correttamente le risorse private? Quindi è possibile accedere a queste risorse in modo dannoso (letto, magari anche modificato o eliminato) da altri utenti non privilegiati. Questo è in genere ciò che hai quando un'applicazione dannosa è in esecuzione sul tuo telefono (non importa se sei stato indotto a installarlo, o se è arrivato qui da solo utilizzando un bug in un'altra applicazione non privilegiata, un browser o un client di posta per istanza) e questa applicazione dannosa tenta di accedere direttamente ad altri dati delle applicazioni o posizioni di archiviazione (può farlo per accedere a dati normalmente non raggiungibili o installarsi in più punti per renderne più difficile la rimozione).
Ecco che arriva SELinux.
SELinux è un sistema MAC (Access Control) obbligatorio. Mentre nel sistema DAC precedentemente descritto gli utenti erano responsabili di impostare il diritto appropriato sulle proprie risorse, con un sistema MAC una politica a livello di sistema (fornita con il sistema operativo) viene applicata sia agli utenti privilegiati che a quelli non privilegiati.
Ciò risolve i due problemi sopra menzionati nei seguenti modi:
- Come ho detto, questa politica si applica anche agli utenti privilegiati. Ciò significa che, con una politica ben progettata, un servizio progettato per gestire la configurazione di rete del dispositivo non sarà in grado di fare nient'altro: ad esempio non avrà accesso agli SMS e un servizio di gestione degli SMS non avrà accesso alla configurazione di rete e nessuno dei due avrà accesso ai dati dell'utente, nonostante entrambi siano in esecuzione utilizzando l'account superutente.
- Android ha recentemente incluso una funzione multiutente che viene applicata da SELinux, impedendo a qualsiasi utente di accedere ai dati di altri utenti. Ma oltre a ciò, la politica SELinux è anche responsabile della descrizione del comportamento consentito delle applicazioni, e molto probabilmente anche se alcune risorse non sono adeguatamente protette usando il sistema DAC SELinux verrà in soccorso e impedirà comunque all'applicazione dannosa di accedervi direttamente.
I sistemi DAC e MAC non si escludono a vicenda, al contrario il sistema MAC (SELinux) funge da secondo livello di difesa dietro il sistema DAC (i tradizionali permessi simili a Unix). Il compito di SELinux è bloccare qualsiasi attività contraria alla politica che, dato solo il sistema DAC, sarebbe altrimenti accettata.
La cosa difficile è che tale politica può essere molto complessa da scrivere: deve infatti coprire tutti i componenti di ogni dispositivo per ogni possibile utilizzo in ogni situazione. In realtà, non importa se qualche azione può essere legittima nella tua situazione: se non è nella politica, è vietato . I criteri mal progettati possono quindi avere conseguenze casuali, come arresti anomali delle applicazioni, funzionalità inutilizzabili e così via.
Ecco perché le prime versioni di SELinux per la spedizione Android lo hanno incluso in modalità "Permissive" per impostazione predefinita. In questa modalità, SELinux registrerà le violazioni dei criteri, ma non tenterà di bloccare l'attività associata. Analizzando i file di registro risultanti, diventa possibile correggere e migliorare la politica fino al punto in cui l'unica violazione della politica rimanente è effettivamente comportamenti dannosi o indesiderati. A questo punto, SELinux può essere trasformato in modalità "Enforcing": ora non solo registra ma blocca anche ogni azione offensiva.
Conclusione
SELinux è una tecnica di mitigazione. Non impedisce agli aggressori di entrare nel tuo telefono, ma assicura che una volta lì possano fare il minor numero di cose possibile, idealmente nulla di utile, rimuovendo in primo luogo l'interesse di attaccare il telefono.
Più vecchia è la ROM, maggiore è il numero di bug di sicurezza che aprirebbe tale accesso. SELinux sarebbe un modo efficiente per mantenere un minimo di sicurezza nonostante queste vulnerabilità note, tuttavia per funzionare correttamente SELinux si affida a una politica complessa.
Se la tua ROM viene fornita con SELinux in modalità "Permissive" per impostazione predefinita, questo probabilmente significa che la politica che contiene non è abbastanza affidabile per passare in sicurezza alla modalità "Enforcing".
Se sei abbastanza tecnico e hai accesso al registro del telefono ( dmesg
almeno, ma di solito sono anche copiati logcat
: ci sono applicazioni che consentono di vedere quest'ultimo, ma a seconda della versione di Android potrebbero richiedere l'accesso come root), puoi verificare se trovi voci "avc": questi sono messaggi che indicano che SELinux ha appena rilevato un'azione contraria alla politica.
Ecco un esempio di tale voce presa dal sito Web di CyanogenMod :
type=AVC msg=audit(1363289005.532:184): avc: denied { read } for pid=29199 comm="Trace"
name="online" dev="sysfs" ino=30 scontext=staff_u:staff_r:googletalk_plugin_t
tcontext=system_u:object_r:sysfs_t tclass=file
Se non ce ne sono, solo alcuni di essi o per qualsiasi motivo pensi che potrebbero non impedirti di usare il telefono, puoi provare a cambiare SELinux in modalità "Enforcing". Nelle vecchie ROM CyanogenMod, questo era facile e possibile semplicemente usando un'opzione nascosta nella GUI (non è necessario eseguire il root del telefono o installare alcuna applicazione specifica), non so se altre ROM offrano la stessa funzionalità ma dal momento che hai usato CyanogenMod tag Suppongo che tu possa essere fortunato;).
setenforce 1
dall'emulatore di terminale (come root)?