Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Concetti di SELinux

Rivedi questa pagina per acquisire familiarità con i concetti di SELinux.

Controllo di accesso obbligatorio

Security Enhanced Linux (SELinux), è un sistema di controllo dell'accesso obbligatorio (MAC) per il sistema operativo Linux. Essendo un sistema MAC, differisce dal familiare sistema di controllo dell'accesso discrezionale (DAC) di Linux. In un sistema DAC, esiste un concetto di proprietà, in base al quale un proprietario di una particolare risorsa controlla le autorizzazioni di accesso ad essa associate. Questo è generalmente a grana grossa e soggetto a un'escalation dei privilegi non intenzionale. Un sistema MAC, tuttavia, consulta un'autorità centrale per una decisione su tutti i tentativi di accesso.

SELinux è stato implementato come parte del framework Linux Security Module (LSM), che riconosce vari oggetti del kernel e azioni sensibili eseguite su di essi. Nel punto in cui ciascuna di queste azioni verrebbe eseguita, viene chiamata una funzione hook LSM per determinare se l'azione deve essere consentita o meno in base alle informazioni per essa memorizzate in un oggetto di sicurezza opaco. SELinux fornisce un'implementazione per questi hook e la gestione di questi oggetti di sicurezza, che si combinano con la propria politica, per determinare le decisioni di accesso.

Insieme ad altre misure di sicurezza Android, la politica di controllo degli accessi di Android limita notevolmente i potenziali danni di computer e account compromessi. L'utilizzo di strumenti come i controlli di accesso discrezionali e obbligatori di Android offre una struttura per garantire che il software venga eseguito solo con il livello di privilegio minimo. Ciò mitiga gli effetti degli attacchi e riduce la probabilità che processi errati sovrascrivono o addirittura trasmettono dati.

In Android 4.3 e versioni successive, SELinux fornisce un controllo di accesso obbligatorio (MAC) sugli ambienti tradizionali di controllo di accesso discrezionale (DAC). Ad esempio, il software deve in genere essere eseguito come account utente root per scrivere su dispositivi a blocchi grezzi. In un ambiente Linux tradizionale basato su DAC, se l'utente root viene compromesso, l'utente può scrivere su ogni dispositivo a blocchi grezzi. Tuttavia, SELinux può essere utilizzato per etichettare questi dispositivi in ​​modo che il processo a cui è stato assegnato il privilegio di root possa scrivere solo su quelli specificati nella policy associata. In questo modo, il processo non può sovrascrivere i dati e le impostazioni di sistema al di fuori del dispositivo a blocchi grezzo specifico.

Vedi casi d'uso per ulteriori esempi di minacce e modi per affrontarli con SELinux.

Livelli di applicazione

SELinux può essere implementato in diverse modalità:

  • Permissivo - La politica di sicurezza di SELinux non viene applicata, ma solo registrata.
  • Applicazione : i criteri di sicurezza vengono applicati e registrati. Gli errori vengono visualizzati come errori EPERM.

Questa scelta è binaria e determina se la politica intraprende un'azione o semplicemente consente di raccogliere potenziali errori. Permissivo è particolarmente utile durante l'implementazione.

Etichette, regole e domini

SELinux dipende dalle etichette per abbinare azioni e politiche. Le etichette determinano ciò che è consentito. Socket, file e processi hanno tutti etichette in SELinux. Le decisioni di SELinux si basano sulle etichette assegnate a questi oggetti e sulla politica che definisce come possono interagire.

In SELinux, un'etichetta assume la forma: user:role:type:mls_level , dove il tipo è il componente principale delle decisioni di accesso, che può essere modificato dalle altre sezioni componenti che compongono l'etichetta. Gli oggetti sono mappati alle classi e i diversi tipi di accesso per ogni classe sono rappresentati dai permessi.

Le regole dei criteri si presentano nella forma: allow domains types : classes permissions ; , dove:

  • Dominio : un'etichetta per il processo o insieme di processi. Chiamato anche tipo di dominio in quanto è solo un tipo per un processo.
  • Tipo : un'etichetta per l'oggetto (ad es. File, socket) o insieme di oggetti.
  • Classe - Il tipo di oggetto (ad esempio file, socket) a cui si accede.
  • Autorizzazione : l'operazione (ad es. Lettura, scrittura) in corso.

E quindi un esempio di utilizzo di questo seguirebbe la struttura:

allow appdomain app_data_file:file rw_file_perms;

Questo dice che tutti i domini delle applicazioni possono leggere e scrivere file etichettati app_data_file . Notare che questa regola si basa sulle macro definite nel file global_macros e altre macro utili possono essere trovate anche nel file te_macros . Le macro vengono fornite per raggruppamenti comuni di classi, autorizzazioni e regole e devono essere utilizzate ogni volta che è possibile per ridurre la probabilità di errori dovuti a negazioni sulle autorizzazioni correlate. Questi file di macro si trovano nella directory system / sepolicy . In Android 8.0 e versioni successive, si trovano nella sottodirectory public con altre separazioni pubbliche supportate.

Oltre a elencare individualmente domini o tipi in una regola, è anche possibile fare riferimento a un insieme di domini o tipi tramite un attributo . Un attributo è semplicemente un nome per un insieme di domini o tipi. Ogni dominio o tipo può essere associato a un numero qualsiasi di attributi. Quando viene scritta una regola che specifica un nome di attributo, tale nome viene automaticamente espanso nell'elenco dei domini o dei tipi associati all'attributo. Ad esempio, l'attributo domain è associato a tutti i domini del processo e l'attributo file_type è associato a tutti i tipi di file.

Usa la sintassi precedente per creare regole avc che costituiscono l'essenza di una policy SELinux. Una regola assume la forma:

RULE_VARIANT SOURCE_TYPES TARGET_TYPES : CLASSES PERMISSIONS

La regola indica cosa dovrebbe accadere quando un soggetto etichettato con uno qualsiasi dei source_types tenta un'azione corrispondente a una qualsiasi delle autorizzazioni su un oggetto con una delle classi di classe che ha una delle etichette target_types . L'esempio più comune di una di queste regole è una regola di autorizzazione, ad esempio:

allow domain null_device:chr_file { open };

Questa regola consente un processo con qualsiasi dominio associato al domain attributo per intraprendere l'azione descritta dal autorizzazione open su un oggetto della classe chr_file (file di dispositivo a caratteri) che ha l'etichetta target_type di null_device . In pratica, questa regola può essere estesa per includere altre autorizzazioni:

allow domain null_device:chr_file { getattr open read ioctl lock append write};

Se combinata con la consapevolezza che il domain è un attributo assegnato a tutti i domini del processo e che null_device è l'etichetta per il dispositivo a carattere /dev/null , questa regola consente fondamentalmente la lettura e la scrittura su /dev/null .

Un dominio generalmente corrisponde a un processo e ha un'etichetta ad esso associata.

Ad esempio, una tipica app Android è in esecuzione nel proprio processo e ha l'etichetta di untrusted_app che le concede determinate autorizzazioni limitate.

Le app della piattaforma integrate nel sistema vengono eseguite con un'etichetta separata e ricevono un set distinto di autorizzazioni. Le app UID di sistema che fanno parte del sistema Android di base vengono eseguite con l'etichetta system_app per un altro set di privilegi.

L'accesso alle seguenti etichette generiche non dovrebbe mai essere consentito direttamente ai domini; invece, dovrebbe essere creato un tipo più specifico per l'oggetto o gli oggetti:

  • socket_device
  • device
  • block_device
  • default_service
  • system_data_file
  • tmpfs