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

Convalida di SELinux

Android incoraggia vivamente gli OEM a testare a fondo le loro implementazioni SELinux. Quando i produttori implementano SELinux, dovrebbero prima applicare la nuova policy a un pool di test di dispositivi.

Dopo aver applicato una nuova policy, assicurati che SELinux sia in esecuzione nella modalità corretta sul dispositivo getenforce il comando getenforce .

Stampa la modalità SELinux globale: Enforcing o Permissive. Per determinare la modalità SELinux per ogni dominio, è necessario esaminare i file corrispondenti o eseguire l'ultima versione di sepolicy-analyze con il flag appropriato ( -p ), presente in /platform/system/sepolicy/tools/ .

Leggere smentite

Verificare la presenza di errori, che vengono instradati come registri eventi a dmesg e logcat e sono visualizzabili localmente sul dispositivo. I produttori dovrebbero esaminare l'output di SELinux in dmesg su questi dispositivi e perfezionare le impostazioni prima del rilascio pubblico in modalità permissiva e l'eventuale passaggio alla modalità enforcing. I messaggi di log di SELinux contengono avc: e quindi possono essere facilmente trovati con grep . È possibile acquisire i log di negazione in corso eseguendo cat /proc/kmsg o acquisire i log di negazione dall'avvio precedente eseguendo cat /sys/fs/pstore/console-ramoops .

Con questo output, i produttori possono facilmente identificare quando gli utenti oi componenti del sistema stanno violando la politica di SELinux. I produttori possono quindi riparare questo cattivo comportamento, modificando il software, la politica di SELinux o entrambi.

In particolare, questi messaggi di registro indicano quali processi fallirebbero in modalità di applicazione e perché. Ecco un esempio:

avc: denied  { connectto } for  pid=2671 comm="ping" path="/dev/socket/dnsproxyd"
scontext=u:r:shell:s0 tcontext=u:r:netd:s0 tclass=unix_stream_socket

Interpreta questo output in questo modo:

  • Il { connectto } sopra rappresenta l'azione intrapresa. Insieme alla tclass alla fine ( unix_stream_socket ), ti dice approssimativamente cosa è stato fatto a cosa. In questo caso, qualcosa stava cercando di connettersi a un socket di flusso unix.
  • Lo scontext (u:r:shell:s0) ti dice quale contesto ha avviato l'azione. In questo caso si tratta di qualcosa che funziona come la shell.
  • Il tcontext (u:r:netd:s0) ti dice il contesto dell'obiettivo dell'azione. In questo caso, è un unix_stream_socket di proprietà di netd .
  • Il comm="ping" in alto fornisce un ulteriore suggerimento su ciò che era in esecuzione al momento in cui è stato generato il rifiuto. In questo caso, è un buon suggerimento.

Un altro esempio:

adb shell su root dmesg | grep 'avc: '

Produzione:

<5> type=1400 audit: avc:  denied  { read write } for  pid=177
comm="rmt_storage" name="mem" dev="tmpfs" ino=6004 scontext=u:r:rmt:s0
tcontext=u:object_r:kmem_device:s0 tclass=chr_file

Ecco gli elementi chiave di questa negazione:

  • Azione : l'azione tentata è evidenziata tra parentesi, read write o setenforce .
  • Attore : la voce scontext (contesto di origine) rappresenta l'attore, in questo caso il daemon rmt_storage .
  • Object - La voce tcontext (target context) rappresenta l'oggetto su cui si agisce, in questo caso kmem.
  • Risultato - La voce tclass (classe di destinazione) indica il tipo di oggetto su cui si agisce, in questo caso un chr_file (dispositivo di caratteri).

Passaggio a permissivo

L'applicazione di SELinux può essere disabilitata tramite ADB su userdebug o eng build. Per fare ciò, per prima cosa cambia ADB in root eseguendo adb root . Quindi, per disabilitare l'applicazione di SELinux, eseguire:

adb shell setenforce 0

O dalla riga di comando del kernel (durante il primo avvio del dispositivo):

androidboot.selinux=permissive
androidboot.selinux=enforcing

Utilizzando audit2allow

Lo strumento selinux/policycoreutils/audit2allow accetta i dinieghi di dmesg e li converte nelle corrispondenti istruzioni della politica di SELinux. In quanto tale, può velocizzare notevolmente lo sviluppo di SELinux. audit2allow viene fornito come parte dell'albero dei sorgenti di Android e viene compilato automaticamente quando si crea Android dal sorgente.

Per usarlo, esegui:

adb pull /sys/fs/selinux/policy
adb logcat -b all -d | audit2allow -p policy

Tuttavia, è necessario prestare attenzione per esaminare ogni potenziale aggiunta per i permessi di superamento. Ad esempio, audit2allow rmt_storage negazione rmt_storage mostrata in precedenza si traduce nella seguente dichiarazione di politica SELinux suggerita:

#============= shell ==============
allow shell kernel:security setenforce;
#============= rmt ==============
allow rmt kmem_device:chr_file { read write };

Ciò garantirebbe a rmt la capacità di scrivere nella memoria del kernel, un evidente buco di sicurezza. Spesso le istruzioni audit2allow sono solo un punto di partenza. Dopo aver utilizzato queste istruzioni, potrebbe essere necessario modificare il dominio di origine e l'etichetta della destinazione, nonché incorporare le macro appropriate, per arrivare a una buona politica. A volte la negazione in esame non dovrebbe comportare alcun cambiamento di politica; piuttosto l'applicazione incriminata dovrebbe essere cambiata.