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
- 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.
- 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.
- Crea e esegui il flashing delle immagini di avvio e di sistema.
- 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.