Implementazione di SELinux

SELinux è impostato su default-deny, il che significa che ogni singolo accesso a cui ha un hook nel kernel deve essere consentito esplicitamente dal criterio. Questo significa che un file di criteri contiene una grande quantità di informazioni relative regole, tipi, classi, autorizzazioni e altro ancora. Una considerazione completa di SELinux non rientra nell'ambito di questo documento, ma una comprensione di come scrivere le regole dei criteri ora sono essenziali quando vengono introdotti nuovi dispositivi Android. C'è un sono già disponibili molte informazioni su SELinux. Vedi Supporto documentazione per le risorse suggerite.

File di chiavi

Per abilitare SELinux, integra più recenti kernel Android e quindi incorporare i file che si trovano nel sistema/politica di trasporto . Una volta compilati, questi file costituiscono la protezione del kernel di SELinux e coprono il sistema operativo Android upstream.

In generale, non modificare i file system/sepolicy strato Add. Puoi invece aggiungere o modificare i tuoi file di criteri specifici per i dispositivi nella /device/manufacturer/device-name/sepolicy . In Android 8.0 e versioni successive, le modifiche apportate a questi file interessano solo i criteri nella directory dei fornitori. Per ulteriori dettagli sulla separazione pubblico sepolicy in Android 8.0 e versioni successive; consulta Personalizzazione di SEPolicy in Android 8.0 e versioni successive. Indipendentemente dalla versione di Android, continuerai a modificare i seguenti file:

File dei criteri

I file che terminano con *.te sono file di origine dei criteri SELinux, che definiscono i domini e le relative etichette. Potrebbe essere necessario creare nuovi file di criteri in /device/manufacturer/device-name/sepolicy, ma dovresti aggiornare i file esistenti, se possibile.

File di contesto

I file di contesto consentono di specificare le etichette per gli oggetti.

  • file_contexts assegna etichette ai file ed è utilizzato da varie dello spazio utente. Quando crei nuovi criteri, crea o aggiorna questo file per assegnare nuove etichette ai file. Per applicare la nuova file_contexts: ricreare l'immagine del file system o eseguire restorecon sul file rietichettare. Per gli upgrade, le modifiche a file_contexts vengono applicate automaticamente alle partizioni dei dati utente e di sistema nell'ambito upgrade. Le modifiche possono essere applicate automaticamente anche durante l'upgrade ad altre partizioni aggiungendo restorecon_recursive chiamate init.board.rc dopo il montaggio della partizione lettura/scrittura.
  • genfs_contexts assegna etichette ai file system, ad esempio proc o vfat che non supportano le estensioni attributi. Questa configurazione viene caricata come parte del criterio del kernel, modifiche potrebbero non essere effettive per gli inode in-core, che richiedono il riavvio o smonta e rimonta il file system per applicare completamente la modifica. Etichette specifiche possono anche essere assegnate a montaggi specifici, come vfat usando l'opzione context=mount.
  • property_contexts assegna etichette alle proprietà di sistema Android a e controllare quali processi possono impostarle. Questa configurazione viene letta Processo init durante l'avvio.
  • service_contexts assegna etichette ai servizi di binder Android a controllare quali processi possono aggiungere (registrare) e trovare (cercare) un raccoglitore di riferimento per il servizio. Questa configurazione viene letta Processo servicemanager durante l'avvio.
  • seapp_contexts assegna etichette ai processi dell'app e /data/data directory. Questa configurazione viene letta Processo zygote a ogni avvio dell'app e entro il giorno installd durante l'avvio.
  • mac_permissions.xml assegna un tag seinfo alle app in base alla firma e, facoltativamente, al nome del pacchetto. La Il tag seinfo può quindi essere utilizzato come chiave in seapp_contexts file per assegnare un'etichetta specifica a tutte le app con quel tag seinfo. Questa configurazione viene letta system_server durante l'avvio.
  • keystore2_key_contexts assegna etichette agli spazi dei nomi dell'archivio chiavi 2.0. Questo spazio dei nomi viene applicato dal daemon keystore2. L'archivio chiavi ha sempre spazi dei nomi basati su UID/AID forniti. Keystore 2.0 applica inoltre sepolicy spazi dei nomi definiti. Una descrizione dettagliata del formato e delle convenzioni di questo disponibile qui.

Makefile di BoardConfig.mk

Dopo aver modificato o aggiunto file di criteri e file di contesto, aggiorna /device/manufacturer/device-name/BoardConfig.mk makefile per fare riferimento alla sottodirectory sepolicy e a ogni nuovo file dei criteri. Per ulteriori informazioni sulle variabili BOARD_SEPOLICY, consulta system/sepolicy/README file.

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Dopo la ricreazione, il dispositivo viene abilitato per SELinux. Ora puoi personalizzare i criteri SELinux per includere le proprie aggiunte al Sistema operativo Android come descritto in Personalizzazione o verifica configurazione esistente, come descritto in Convalida.

Una volta implementati i nuovi file dei criteri e gli aggiornamenti di BoardConfig.mk, le impostazioni dei criteri vengono incorporate automaticamente nel file finale dei criteri del kernel. Per ulteriori informazioni su come sepolicy è realizzato sul dispositivo, vedi Creazione di sepolicy.

Implementazione

Per iniziare a utilizzare SELinux:

  1. Abilita SELinux nel kernel: CONFIG_SECURITY_SELINUX=y
  2. Modifica il parametro kernel_cmdline o bootconfig in modo che: 
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    o 
    BOARD_BOOTCONFIG := androidboot.selinux=permissive
    Serve solo per lo sviluppo iniziale dei criteri per il dispositivo. Dopo un criterio di bootstrap iniziale, rimuovi questo parametro in modo che dispositivo in fase di applicazione, altrimenti CTS non andrà a buon fine.
  3. Avvia il sistema in modalità permissiva e controlla quali rifiuti vengono riscontrati all'avvio:
    Su Ubuntu 14.04 o versioni successive: 
    adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
    Su Ubuntu 12.04: 
    adb pull /sys/fs/selinux/policy
adb logcat -b all | audit2allow -p policy
  4. Valuta l'output per avvisi simili a init: Warning! Service name needs a SELinux domain defined; please fix! Vedi Convalida per le istruzioni e strumenti.
  5. Identifica dispositivi e altri nuovi file che devono essere etichettati.
  6. Utilizza etichette esistenti o nuove per gli oggetti. Osserva la *_contexts file per vedere l'etichetta precedente degli elementi e usa la conoscenza dei significati delle etichette per assegnarne una nuova. L'ideale è si tratta di un'etichetta esistente che rientra nelle norme, ma a volte sarà necessaria una nuova etichetta e le regole per accedervi saranno necessaria. Aggiungi le etichette ai file di contesto appropriati.
  7. Identificare domini/processi che dovrebbero avere i propri domini di sicurezza. Probabilmente dovrai scrivere norme completamente nuove per ciascuno di essi. Tutti servizi generati da init, ad esempio, devono avere i loro personali. I seguenti comandi aiutano a individuare quelli che rimangono in esecuzione (ma TUTTI che richiedono un trattamento di questo tipo:
    adb shell su -c ps -Z | grep init

    adb shell su -c dmesg | grep 'avc: '
  8. Esamina init.device.rc per identificare i domini che non hanno un tipo di dominio. Fornisci loro un dominio in anticipo nel tuo di sviluppo per evitare di aggiungere regole a init altrimenti confondere gli accessi di init con gli accessi delle tue norme.
  9. Configura BOARD_CONFIG.mk per usare BOARD_SEPOLICY_* come la codifica one-hot delle variabili categoriche. Consulta le README in system/sepolicy per i dettagli sulla configurazione.
  10. Esamina il file init.device.rc e fstab.device e che ogni utilizzo di mount corrisponda a una un file system etichettato o che un'opzione context= mount sia specificato.
  11. Esamina ogni rifiuto e crea un criterio SELinux per gestirli correttamente. Consulta gli esempi in Personalizzazione.

Dovresti iniziare con i criteri nell'AOSP e poi utilizzarli per le tue personalizzazioni. Per ulteriori informazioni sulla strategia per le norme e su un da un'occhiata più da vicino ad alcuni di questi passaggi, Scrittura di un criterio SELinux.

Casi d'uso

Ecco alcuni esempi specifici di exploit da considerare quando crei i tuoi software e criteri SELinux associati:

Link simbolici: poiché appaiono come file, spesso sono leggi come file, il che può portare a exploit. Ad esempio, alcuni privilegi ad esempio init, modificano le autorizzazioni di determinati file, essere troppo aperti.

Gli aggressori potrebbero poi sostituire questi file con collegamenti simbolici al codice che controllano, consentendo all'hacker di sovrascrivere file arbitrari. Ma se conosci un'applicazione non attraverserà mai un link simbolico, puoi vietarle di farlo con SELinux.

File di sistema: considera la classe dei file di sistema che deve essere modificato solo dal server di sistema. Sempre da netd, init e vold vengono eseguiti come root; possono accedere file di sistema. Quindi, se netd venisse compromesso, potrebbe compromettere i file e potenzialmente lo stesso server di sistema.

Con SELinux, puoi identificare questi file come file di dati del server di sistema. Pertanto, l'unico dominio che dispone dell'accesso in lettura/scrittura è il server di sistema. Anche se netd venisse compromesso, non poteva passare da un dominio all'altro dominio del server di sistema e accedere a questi file di sistema anche se viene eseguito come root.

Dati dell'app. Un altro esempio è la classe di funzioni che deve essere eseguito come root ma non deve accedere ai dati dell'app. È un aspetto incredibile utile perché è possibile fare asserzioni di ampio respiro, come alcuni domini non correlati all'interdizione dell'accesso a Internet da parte dei dati delle applicazioni.

setattr - Per comandi come chmod e chown, potresti identificare l'insieme di file in cui sono associati il dominio può condurre setattr. Al di fuori di questo ambito, proibiti da queste modifiche, anche dalla directory radice. Quindi un'applicazione potrebbe eseguire chmod e chown rispetto a quelli etichettati app_data_files ma non shell_data_files o system_data_files.