Scrittura di criteri SELinux

Android Open Source Project (AOSP) offre una solida base policy per il applicazioni e servizi comuni a tutti i dispositivi Android. I collaboratori di AOSP perfezionano regolarmente questa norma. Il criterio fondamentale è previsto pari a circa il 90-95% del criterio on-device finale con criteri personalizzazioni che costituiscono il restante 5-10%. Questo articolo riguarda gli argomenti queste personalizzazioni specifiche per dispositivo, come scrivere criteri specifici per il dispositivo alcune insidie da evitare lungo il percorso.

Visualizzazione dispositivo

Durante la scrittura di criteri specifici per i dispositivi, segui questi passaggi.

Esegui in modalità permissiva

Quando un dispositivo è in posizione modalità permissiva, i rifiuti vengono registrati ma non applicati. La modalità permissiva è importante motivi:

• La modalità permissiva assicura che la generazione dei criteri non ritardasse altre in anticipo attività di visualizzazione del dispositivo.
• Un rifiuto forzato può mascherare altri rifiuti. Ad esempio, l'accesso ai file prevede in genere una ricerca nella directory, l'apertura del file e la lettura del file. Nella modalità di applicazione forzata, si verificherà solo il rifiuto della ricerca nella directory. Permissiva assicura che tutti i rifiuti vengano visualizzati.

Il modo più semplice per impostare un dispositivo in modalità permissiva è utilizzare comando kernel riga di comando. Puoi aggiungere questo elemento al file BoardConfig.mk del dispositivo: platform/device/<vendor>/<target>/BoardConfig.mk. Dopo aver modificato la riga di comando, esegui make clean, quindi make bootimage e esegui il flashing della nuova immagine di avvio.

Dopodiché, conferma la modalità permissiva con:

adb shell getenforce

Due settimane sono un periodo di tempo ragionevole per essere in modalità permissiva globale. Dopo aver risolto la maggior parte dei rifiuti, torna alla modalità di applicazione forzata e risolvere eventuali bug non appena arrivano. Domini che continuano a produrre rifiuti o servizi in fase di sviluppo intensivo possono essere messi temporaneamente in modalità permissiva, ma per ripristinare la modalità di applicazione forzata il prima possibile.

Applica in anticipo

In modalità di applicazione forzata, i rifiuti vengono registrati e applicati. È una per attivare la modalità di applicazione forzata sul tuo dispositivo il prima possibile. In attesa di la creazione e l'applicazione di norme specifiche per i dispositivi spesso comportano la presenza di un prodotto con bug e di una un'esperienza utente negativa. Inizia abbastanza presto per partecipare versione sperimentale e garantire una copertura di test completa delle funzionalità nell'uso reale. In fase di avvio precoce, garantisce che le decisioni di progettazione siano basate su problemi di sicurezza. Al contrario, la concessione le autorizzazioni basate esclusivamente sui rifiuti osservati è un approccio non sicuro. Usa questa occorre eseguire un controllo di sicurezza del dispositivo e segnalare bug in base al comportamento che non dovrebbero essere consentiti.

Rimuovi o elimina il criterio esistente

Esistono una serie di buoni motivi per creare criteri specifici per dispositivo da da zero su un nuovo dispositivo, tra cui:

• Controllo di sicurezza
• Norme eccessivamente permissive
• Riduzione delle dimensioni dei criteri
• Norme sui morti

Gestire i rifiuti dei servizi principali

I rifiuti generati dai servizi principali in genere vengono gestiti con l'etichettatura dei file. Ad esempio:

avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0”
dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
tclass=chr_file permissive=1
avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs"
scontext=u:r:mediaserver:s0
tcontext=u:object_r:device:s0 tclass=chr_file permissive=1

viene completamente risolto etichettando correttamente /dev/kgsl-3d0. Nella in questo esempio, tcontext è device. Questo rappresenta contesto predefinito in cui tutto ciò che in /dev riceve " dispositivo", a meno che non venga assegnata un'etichetta più specifica. Accettazione semplice l'output audit2allow potrebbe comportare una regola errata ed eccessivamente permissiva.

Per risolvere questo tipo di problema, assegna al file un'etichetta più specifica, che questo caso è gpu_device. Non sono necessarie ulteriori autorizzazioni perché mediaserver dispone già delle autorizzazioni necessarie nel criterio principale per accedere a gpu_device.

Altri file specifici del dispositivo che devono essere etichettati con tipi predefiniti in norme principali:

• dispositivi a blocchi
• dispositivi audio
• dispositivi video
• sensori
• nfc
• dispositivo_gps
• file in /sys
• file in /proc

In generale, la concessione delle autorizzazioni alle etichette predefinite non è corretta. Molti di questi le autorizzazioni non sono consentite da neverallow, ma anche quando non è esplicitamente vietato, la best practice è fornire un indirizzo dell'etichetta.

Etichetta nuovi servizi e indirizzi rifiuti

I servizi lanciati da init devono essere eseguiti nei rispettivi domini SELinux. La nell'esempio seguente inserisce il servizio "foo" nel proprio dominio SELinux e lo concede autorizzazioni aggiuntive.

Il servizio è stato lanciato nella console init.device.rc file come:

service foo /system/bin/foo
    class core

1. Crea un nuovo dominio "foo"
   

   Crea il file device/manufacturer/device-name/sepolicy/foo.te con i seguenti contenuti:

   # foo service
   type foo, domain;
   type foo_exec, exec_type, file_type;
   
   init_daemon_domain(foo)
   

   Questo è il modello iniziale per il dominio foo SELinux, a cui possono aggiungere regole basate sulle operazioni specifiche eseguite dall'eseguibile.

2. Etichetta /system/bin/foo
   

   Aggiungi quanto segue a device/manufacturer/device-name/sepolicy/file_contexts:

   /system/bin/foo   u:object_r:foo_exec:s0
   

   Ciò garantisce che l'eseguibile sia etichettato correttamente in modo che SELinux esegua nel dominio corretto.

3. Crea e esegui il flashing delle immagini di avvio e di sistema.
4. Perfeziona le regole SELinux per il dominio.
   

   Utilizza i rifiuti per determinare le autorizzazioni richieste. La audit2allow fornisce buone linee guida, ma lo usa solo per definire le norme scrivere a voce alta. Non semplicemente copiare l'output.

Torna alla modalità di applicazione forzata

Puoi risolvere i problemi in modalità permissiva, ma torna all'applicazione forzata il prima possibile e cercare di rimanere tale.

Errori comuni

Di seguito sono riportate alcune soluzioni per gli errori comuni che si verificano durante la scrittura criteri specifici per i dispositivi.

Utilizzo eccessivo della negazione

La seguente regola di esempio è come chiudere la serratura della porta d'ingresso senza uscire finestre aperte:

allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms

Lo scopo è chiaro: tutti, tranne le app di terze parti, potrebbero avere accesso al debug dispositivo.

La regola presenta alcune imperfezioni. L'esclusione di untrusted_app non è facile, perché tutte le app possono eseguire facoltativamente servizi nel isolated_app dominio. Analogamente, se nuovi domini per app di terze parti vengono aggiunti ad AOSP, avranno accesso anche a scary_debug_device. La regola è eccessivamente permissiva. La maggior parte dei domini non trarrà vantaggio dall'avere l'accesso a questo strumento di debug. La regola dovrebbe essere stata scritta per consentire ai domini che richiedono l'accesso.

Debug delle funzionalità in produzione

Le funzionalità di debug non devono essere presenti né nelle build di produzione .

L'alternativa più semplice è consentire la funzionalità di debug solo quando SELinux è Funzionalità disabilitata per le build eng/userdebug, come adb root e adb shell setenforce 0.

Un'altra alternativa sicura è includere le autorizzazioni di debug in un userdebug_or_eng.

Esplosione delle dimensioni dei criteri

Caratterizzare i criteri SEAndroid in circolazione descrive una tendenza preoccupante nella crescita delle personalizzazioni dei criteri relativi ai dispositivi. I criteri specifici per dispositivo devono rappresentare il 5-10% del criterio complessivo in esecuzione su un dispositivo. Le personalizzazioni nell'intervallo oltre il 20%contengono quasi certamente oltre con privilegi e criteri non attivi.

Norme inutilmente di grandi dimensioni:

• Riceve un doppio hit sulla memoria perché il criterio si trova nel ramdisk e viene sono stati caricati anche nella memoria del kernel.
• Spreca spazio su disco richiedendo un'immagine di avvio più grande.
• Interessa i tempi di ricerca dei criteri di runtime.

L'esempio seguente mostra due dispositivi in cui l'impostazione costituiscono il 50% e il 40% dei criteri sul dispositivo. Una riscrittura del criterio ha prodotto miglioramenti sostanziali della sicurezza senza perdita di funzionalità, poiché come mostrato di seguito. I dispositivi AOSP Shamu e Flounder sono inclusi per il confronto.

Figura 1. Confronto per dispositivi specifici dimensioni del criterio dopo il controllo di sicurezza.

In entrambi i casi, la politica è stata drasticamente ridotta, sia per le dimensioni che per il numero di autorizzazioni. La diminuzione delle dimensioni dei criteri è quasi completamente dovuta alla rimozione autorizzazioni non necessarie, molte delle quali erano probabilmente regole generate audit2allow che sono stati aggiunti in modo indiscriminato al criterio. Morto era un problema anche per entrambi i dispositivi.

Concessione della funzionalità dac_override

Un dac_override rifiuto significa che il processo in questione viene tentativo di accedere a un file con autorizzazioni utente/gruppo/mondo Unix errate. La soluzione corretta non è quasi mai concedere l'autorizzazione dac_override. Invece modificare le autorizzazioni unix sul file o sul processo. Alcuni domini come init, vold e installd hanno davvero bisogno Possibilità di ignorare le autorizzazioni dei file unix per accedere ai file di altri processi. Consulta il blog di Dan Walsh per una spiegazione più approfondita.