Consulta questa pagina per acquisire familiarità con i concetti di SELinux.
Controllo dell'accesso obbligatorio
Security Advanced Linux (SELinux) è un sistema MAC, obbligatorio per il controllo degli accessi per il sistema operativo Linux. Come sistema MAC, si differenzia dalle il familiare sistema di controllo degli accessi discrezionale (DAC). In un sistema DAC, un concetto di proprietà esistente, per cui un proprietario di una particolare risorsa controlla l'accesso autorizzazioni associate. In genere è molto dettagliato e riguarda a un'escalation involontaria dei privilegi. Un sistema MAC, tuttavia, consulta un l'autorità competente per una decisione su tutti i tentativi di accesso.
SELinux è stato implementato come parte del Linux Security Module (LSM) che riconosce vari oggetti kernel e azioni sensibili eseguito su di essi. Nel punto in cui ognuna di queste azioni viene eseguita, viene chiamata una funzione hook LSM per determinare se l'azione deve essere consentita in base alle relative informazioni di sicurezza. SELinux fornisce un'implementazione per questi hook e di questi oggetti, che si combinano con i suoi criteri, per determinare le decisioni di accesso.
Insieme ad altre misure di sicurezza, il controllo dell'accesso di Android limita notevolmente i potenziali danni dei computer compromessi . Usare strumenti come l'accesso discrezionale e obbligatorio di Android di controllo fornisce una struttura per garantire che il software venga eseguito livello di privilegio. In questo modo si mitigano gli effetti degli attacchi e si riducono probabilità che i processi erronei sovrascrivano o trasmettano dati.
In Android 4.3 e versioni successive, SELinux fornisce un controllo dell'accesso obbligatorio (MAC) ambienti tradizionali con controllo degli accessi discrezionali (DAC). Per Ad esempio, il software in genere deve essere eseguito come account utente root per poter scrivere sui dati non elaborati bloccare i dispositivi. In un ambiente Linux tradizionale basato su DAC, se l'utente root viene compromesso il fatto che l'utente possa scrivere su ogni dispositivo a blocchi non elaborati. Tuttavia, È possibile utilizzare SELinux per etichettare questi dispositivi in modo che il processo abbia assegnato può scrivere solo su quelli specificati nel criterio associato. In questo il processo non può sovrascrivere dati e impostazioni di sistema al di fuori del dispositivo di blocco non elaborato specifico.
Vedi Casi d'uso per altri esempi di minacce e dei modi per risolverle con SELinux.
Livelli di applicazione delle norme
SELinux può essere implementato in diverse modalità:
- Permissiva: il criterio di sicurezza SELinux non viene applicato in modo forzato, ma viene solo registrato.
- Applicazione forzata: il criterio di sicurezza viene applicato e registrato in modo forzato. Errori vengono visualizzati come errori EPERM.
Questa scelta è binaria e determina se il criterio agisce o solo consente di raccogliere potenziali errori. La strategia permissiva è particolarmente utile implementazione.
Tipi, attributi e regole
Android si affida al componente TE (Type Enforcement) di SELinux per
. Significa che tutti gli oggetti (come file, processo o socket) hanno un
type associato. Ad esempio, per impostazione predefinita,
avrà il tipo untrusted_app. Per un processo, anche il suo tipo è
noto come dominio. È possibile annotare un tipo con uno o
molti attributi. Gli attributi sono utili per fare riferimento a più tipi
contemporaneamente.
Gli oggetti sono mappati alle classi
(ad es. un file, una directory, un link simbolico, un socket) e i diversi tipi di accesso
per ogni classe sono rappresentate dalle autorizzazioni.
Ad esempio, l'autorizzazione open esiste per la classe
file. Sebbene tipi e attributi vengano aggiornati regolarmente nell'ambito
il criterio, le autorizzazioni e le classi di Android SELinux sono definite in modo statico
raramente aggiornati nell'ambito di una nuova release di Linux.
Una regola di un criterio si presenta nel seguente formato:
allow source target:class permissions;
dove:
- Origine: il tipo (o attributo) dell'oggetto della regola. Chi richiede l'accesso?
- Target: il tipo (o attributo) dell'oggetto. A quale scopo è richiesto l'accesso?
- Class - Il tipo di oggetto (ad es. file, socket) a cui si accede.
- Autorizzazioni: l'operazione (o l'insieme di operazioni) (ad esempio lettura e scrittura) che viene eseguita.
Un esempio di regola è:
allow untrusted_app app_data_file:file { read write };
Ciò indica che le app sono autorizzate a leggere e scrivere file etichettati
app_data_file. Esistono altri tipi di app. Per
istanze, isolated_app è utilizzata per i servizi delle app
isolatedProcess=true nel file manifest. Invece di ripetere
regola per entrambi i tipi, Android utilizza un attributo denominato appdomain
per tutti i tipi di app:
# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app, appdomain;
# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app, appdomain;
allow appdomain app_data_file:file { read write };
Quando viene scritta una regola che specifica il nome di un attributo, tale nome viene automaticamente all'elenco di domini o tipi associati . Alcuni attributi degni di nota sono:
domain- attributo associato a tutti i tipi di processo,file_type- attributo associato a tutti i tipi di file.
Macro
Per quanto riguarda l'accesso ai file, esistono molti tipi di autorizzazioni per
considerare. Ad esempio, l'autorizzazione read non è sufficiente per aprire l'elemento
o chiamare stat. Per semplificare la definizione della regola, Android
fornisce un insieme di macro per gestire i casi più comuni. Ad esempio, nell'ordine
per includere le autorizzazioni mancanti, come open, la regola riportata sopra
potrebbe essere riscritto come:
allow appdomain app_data_file:file rw_file_perms;
Consulta la global_macros
e te_macros
per altri esempi di macro utili. Le macro devono essere utilizzate ogni volta che è possibile
per ridurre la probabilità di errori dovuti a rifiuti su
autorizzazioni aggiuntive.
Una volta definito, il tipo deve essere associato al file o al processo che rappresenta. Consulta Implementazione di SELinux per maggiori dettagli su come viene eseguita questa associazione. Per ulteriori informazioni vedi le regole Blocco note di SELinux.
Contesto e categorie di sicurezza
Durante il debug dei criteri SELinux o dei file di etichettatura (tramite
file_contexts o quando chiami ls -Z), potresti entrare
in un contesto di sicurezza (chiamato anche etichetta). Per
esempio:
u:r:untrusted_app:s0:c15,c256,c513,c768. Un contesto di sicurezza ha il seguente formato:
user:role:type:sensitivity[:categories]. Di solito, puoi ignorare
user, role e sensitivity campi di
il contesto (vedi Specificità). type
è spiegato nella sezione precedente. categories fanno parte di
sulla sicurezza multilivello (MLS)
di destinazione in SELinux. A partire da Android S, le categorie vengono usate per:
- Isolare i dati dell'app per impedire l'accesso da parte di un'altra app.
- Isolare i dati dell'app da un utente fisico all'altro.
Specificità
Android non utilizza tutte le funzionalità fornite da SELinux. Durante la lettura documentazione esterna, tieni presente i seguenti punti:
- La maggior parte dei criteri in AOSP è definita utilizzando il linguaggio dei criteri del kernel. Esistono alcune eccezioni per l'utilizzo del Common Intermediate Language (CIL).
- Gli utenti SELinux non vengono utilizzati. L'unico utente definito è
uSe necessario, gli utenti fisici sono rappresentati utilizzando il campo delle categorie di un contesto di sicurezza. - I ruoli SELinux e il controllo dell'accesso basato su ruoli (RBAC) non vengono utilizzati. Vengono definiti e utilizzati due ruoli predefiniti:
rper i soggetti eobject_rper gli oggetti. - Le sensibilità di SELinux non vengono utilizzate. La sensibilità predefinita di
s0è sempre impostata. - I valori booleani di SELinux non vengono utilizzati. Una volta creato il criterio per un dispositivo, non dipende dallo stato del dispositivo. Ciò semplifica l'auditing e il debug dei criteri.