Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Implementazione di SELinux

SELinux è impostato su default-deny, il che significa che ogni singolo accesso per cui ha un hook nel kernel deve essere esplicitamente consentito dalla policy. Ciò significa che un file delle politiche comprende una grande quantità di informazioni relative a regole, tipi, classi, autorizzazioni e altro. Una piena considerazione di SELinux non rientra nell'ambito di questo documento, ma la comprensione di come scrivere le regole dei criteri è ora essenziale quando si aprono nuovi dispositivi Android. Sono già disponibili molte informazioni su SELinux. Consulta la documentazione di supporto per le risorse suggerite.

File chiave

Per abilitare SELinux, integrare l' ultimo kernel Android e quindi incorporare i file trovati nella directory system / sepolicy . Una volta compilati, questi file comprendono la politica di sicurezza del kernel SELinux e coprono il sistema operativo Android upstream.

In generale, non è necessario modificare direttamente i file di system/sepolicy . Invece, aggiungere o modificare i propri file dei criteri specifici del dispositivo nel /device/ manufacturer / device-name /sepolicy directory. In Android 8.0 e versioni successive, le modifiche apportate a questi file dovrebbero influire solo sui criteri nella directory del fornitore. Per maggiori dettagli sulla separazione della sepolicy pubblica in Android 8.0 e versioni successive, vedere Personalizzazione di SEPolicy in Android 8.0+ . Indipendentemente dalla versione di Android, stai ancora modificando questi file:

File delle politiche

I file che terminano con *.te sono file sorgente della politica SELinux, che definiscono i domini e le loro etichette. Potrebbe essere necessario creare nuovi file di criteri in /device/ manufacturer / device-name /sepolicy , ma dovresti provare ad aggiornare i file esistenti dove possibile.

File contestuali

I file di contesto sono i punti in cui si specificano le etichette per i propri oggetti.

  • file_contexts assegna le etichette ai file e viene utilizzato da vari componenti dello file_contexts utente. Quando si creano nuovi criteri, creare o aggiornare questo file per assegnare nuove etichette ai file. Per applicare nuovi file_contexts , ricostruire l'immagine del filesystem o eseguire restorecon sul file da rietichettare. Durante gli aggiornamenti, le modifiche a file_contexts vengono automaticamente applicate al sistema e alle partizioni userdata come parte dell'aggiornamento. Le modifiche possono anche essere applicate automaticamente durante l'aggiornamento ad altre partizioni aggiungendo chiamate restorecon_recursive al tuo init. board .rc file dopo che la partizione è stata montata in lettura-scrittura.
  • genfs_contexts assegna etichette ai filesystem, come proc o vfat che non supportano gli attributi estesi. Questa configurazione viene caricata come parte della politica del kernel, ma le modifiche potrebbero non avere effetto per gli in-core in-core, che richiedono un riavvio o lo smontaggio e il re-montaggio del filesystem per applicare completamente la modifica. Etichette specifiche possono anche essere assegnate a specifici mount, come vfat usando l'opzione context=mount .
  • property_contexts assegna le etichette alle proprietà del sistema Android per controllare quali processi possono impostarle. Questa configurazione viene letta dal processo init durante l'avvio.
  • service_contexts assegna etichette ai servizi di binder Android per controllare quali processi possono aggiungere (registrarsi) e trovare (cercare) un riferimento di binder per il servizio. Questa configurazione viene letta dal processo di servicemanager durante l'avvio.
  • seapp_contexts assegna le etichette ai processi delle app e /data/data directory /data/data . Questa configurazione viene letta dal processo zygote all'avvio di ogni app e da installd durante l'avvio.
  • mac_permissions.xml assegna un tag seinfo alle app in base alla loro firma e facoltativamente al nome del loro pacchetto. Il tag seinfo può quindi essere utilizzato come chiave nel file seapp_contexts per assegnare un'etichetta specifica a tutte le app con quel tag seinfo . Questa configurazione viene letta da system_server durante l'avvio.

BoardConfig.mk makefile

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

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

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Dopo la ricostruzione, il tuo dispositivo è abilitato con SELinux. Ora puoi personalizzare i tuoi criteri SELinux per adattarli alle tue aggiunte al sistema operativo Android come descritto in Personalizzazione o verificare la tua configurazione esistente come descritto in Convalida .

Quando sono presenti i nuovi file delle politiche e gli aggiornamenti di BoardConfig.mk, le nuove impostazioni delle politiche vengono automaticamente integrate nel file delle politiche del kernel finale. Per ulteriori informazioni sulla modalità di creazione di sepolicy sul dispositivo, vedere Creazione di sepolicy .

Implementazione

Per iniziare con SELinux:

  1. Abilita SELinux nel kernel: CONFIG_SECURITY_SELINUX=y
  2. Modificare il parametro kernel_cmdline in modo che:
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    Questo è solo per lo sviluppo iniziale della politica per il dispositivo. Dopo aver adottato un criterio di bootstrap iniziale, rimuovere questo parametro in modo che il dispositivo venga applicato o fallirà CTS.
  3. Avviare il sistema in modo permissivo e vedere quali rifiuti si incontrano 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. Valutare l'output per avvisi simili a init: Warning! Service name needs a SELinux domain defined; please fix! Vedi Convalida per istruzioni e strumenti.
  5. Identifica i dispositivi e altri nuovi file che richiedono un'etichettatura.
  6. Usa etichette esistenti o nuove per i tuoi oggetti. Guarda i file *_contexts per vedere come le cose erano state precedentemente etichettate e usa la conoscenza dei significati delle etichette per assegnarne una nuova. Idealmente, questa sarà un'etichetta esistente che si adatterà alla politica, ma a volte sarà necessaria una nuova etichetta e saranno necessarie regole per l'accesso a tale etichetta. Aggiungi le tue etichette ai file di contesto appropriati.
  7. Identificare domini / processi che dovrebbero avere i propri domini di sicurezza. Probabilmente dovrai scrivere una politica completamente nuova per ciascuno. Tutti i servizi generati da init , ad esempio, dovrebbero avere i propri. I seguenti comandi aiutano a rivelare quelli che rimangono in esecuzione (ma TUTTI i servizi necessitano di tale trattamento):
    adb shell su -c ps -Z | grep init
    
    adb shell su -c dmesg | grep 'avc: '
    
  8. Recensione init. device .rc per identificare eventuali domini che non hanno un tipo di dominio. Assegna loro un dominio nelle prime fasi del processo di sviluppo per evitare l'aggiunta di regole a init o la confusione degli accessi a init che rientrano nella loro politica.
  9. Imposta BOARD_CONFIG.mk per utilizzare le variabili BOARD_SEPOLICY_* . Vedere il file README in system/sepolicy per i dettagli sulla configurazione.
  10. Esamina l'init. device .rc e fstab. file del device e assicurarsi che ogni utilizzo di mount corrisponda a un filesystem correttamente etichettato o che sia specificata un'opzione context= mount .
  11. Passare attraverso ogni rifiuto e creare una politica SELinux per gestirli correttamente. Vedi gli esempi in Personalizzazione .

Dovresti iniziare con le politiche nell'AOSP e poi basarti su di esse per le tue personalizzazioni. Per ulteriori informazioni sulla strategia della politica e uno sguardo più da vicino ad alcuni di questi passaggi, vedere Scrivere la politica SELinux .

Casi d'uso

Ecco alcuni esempi specifici di exploit da considerare quando si crea il proprio software e le politiche SELinux associate:

Collegamenti simbolici : poiché i collegamenti simbolici vengono visualizzati come file, vengono spesso letti come file, il che può comportare exploit. Ad esempio, alcuni componenti privilegiati, come init , cambiano le autorizzazioni di alcuni file, a volte per essere eccessivamente aperti.

Gli aggressori potrebbero quindi sostituire quei file con collegamenti simbolici al codice che controllano, consentendo all'autore dell'attacco di sovrascrivere file arbitrari. Ma se sai che la tua applicazione non attraverserà mai un collegamento simbolico, puoi proibirlo con SELinux.

File di sistema : considerare la classe di file di sistema che deve essere modificata solo dal server di sistema. Tuttavia, poiché netd , init e vold eseguiti come root, possono accedere a quei file di sistema. Quindi, se netd compromesso, potrebbe compromettere quei file e potenzialmente il server di sistema stesso.

Con SELinux, è possibile identificare quei file come file di dati del server di sistema. Pertanto, l'unico dominio che ha accesso in lettura / scrittura ad essi è il server di sistema. Anche se netd stato compromesso, non potrebbe cambiare i domini nel dominio del server di sistema e accedere a quei file di sistema sebbene funzioni come root.

Dati app : un altro esempio è la classe di funzioni che devono essere eseguite come root ma non devono accedere ai dati delle app. Ciò è incredibilmente utile in quanto è possibile formulare affermazioni ad ampio raggio, ad esempio alcuni domini non correlati ai dati delle applicazioni vietati dall'accesso a Internet.

setattr - Per comandi come chmod e chown , è possibile identificare il set di file in cui il dominio associato può condurre setattr . Qualunque cosa al di fuori di questo potrebbe essere vietata da questi cambiamenti, anche da root. Quindi un'applicazione potrebbe eseguire chmod e chown con quei file app_data_files etichettati ma non shell_data_files o system_data_files .