Android consiglia vivamente agli OEM di testare attentamente le loro implementazioni di SELinux. Quando i produttori implementano SELinux, devono prima applicare il nuovo criterio a un pool di test di dispositivi.
Dopo aver applicato un nuovo criterio, assicurati che SELinux sia in esecuzione nella modalità corretta sul dispositivo inviando il comando getenforce.
Viene stampata la modalità SELinux globale: Enforcing o Permissive. Per determinare la modalità SELinux per ciascun dominio, devi esaminare i file corrispondenti o eseguire l'ultima versione di sepolicy-analyze con il flag (-p) appropriato, presente in
/platform/system/sepolicy/tools/.
Leggere i rifiuti
Controlla la presenza di errori, che vengono inoltrati come log eventi a dmesg
e logcat e sono visualizzabili localmente sul dispositivo. I produttori devono esaminare l'output di SELinux su dmesg su questi dispositivi e perfezionare le impostazioni prima del rilascio pubblico in modalità permissiva e dell'eventuale passaggio alla modalità di applicazione. I messaggi di log di SELinux contengono avc: e possono essere facilmente trovati con grep. È possibile acquisire i log di rifiuto in corso eseguendo cat /proc/kmsg o i log di rifiuto dall'avvio precedente eseguendo cat /sys/fs/pstore/console-ramoops.
I messaggi di errore SELinux sono limitati in base alla frequenza al termine dell'avvio per evitare di intasare
i log. Per assicurarti di vedere tutti i messaggi pertinenti, puoi disattivare questa opzione eseguendo adb shell auditctl -r 0.
Con questo output, i produttori possono identificare facilmente quando gli utenti o i componenti di sistema violano i criteri SELinux. I produttori possono quindi correggere questo comportamento scorretto modificando il software, le norme SELinux o entrambi.
In particolare, questi messaggi di log indicano quali processi potrebbero non riuscire 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 simbolo
{ connectto }sopra riportato indica l'azione intrapresa. Insieme atclassalla fine (unix_stream_socket), ti dice indicativamente cosa è stato fatto e cosa è stato fatto. In questo caso, qualcosa stava tentando di connettersi a una socket stream Unix. -
scontext (u:r:shell:s0)indica il contesto che ha avviato l'azione. In questo caso, si tratta di un elemento in esecuzione come shell. -
tcontext (u:r:netd:s0)indica il contesto del target dell'azione. In questo caso, si tratta di un unix_stream_socket di proprietà dinetd. - Il simbolo
comm="ping"in alto fornisce un ulteriore suggerimento su cosa veniva eseguito al momento della generazione del rifiuto. In questo caso, il suggerimento è piuttosto buono.
Ecco un altro esempio:
adb shell su root dmesg | grep 'avc: '
Uscita:
<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 questo rifiuto:
- Azione: l'azione tentata è evidenziata tra parentesi quadre (
read writeosetenforce). - Attore: la voce
scontext(contesto di origine) rappresenta l'attore, in questo caso il daemonrmt_storage. - Oggetto: la voce
tcontext(contesto di destinazione) rappresenta l'oggetto su cui si agisce, in questo caso kmem. - Risultato: la voce
tclass(classe target) indica il tipo di oggetto su cui si agisce, in questo caso unchr_file(dispositivo a caratteri).
Esegui il dump degli stack utente e del kernel
In alcuni casi, le informazioni contenute nel log eventi non sono sufficienti per individuare l'origine del rifiuto. Spesso è utile raccogliere la catena di chiamate, inclusi kernel e spazio utente, per comprendere meglio il motivo del rifiuto.
I kernel recenti definiscono un tracepoint denominato avc:selinux_audited. Utilizza Android
simpleperf per abilitare questo tracepoint e acquisire la callchain.
Configurazione supportata
- Kernel Linux >= 5.10, in particolare i rami comuni del kernel Android mainline e android12-5.10 sono supportati.
È supportato anche il ramo android12-5.4. Puoi utilizzare
simpleperfper determinare se il punto traccia è definito sul tuo dispositivo:adb root && adb shell simpleperf list | grep avc:selinux_audited. Per altre versioni del kernel, puoi scegliere i commit dd81662 e 30969bc. - Dovrebbe essere possibile riprodurre l'evento di cui stai eseguendo il debug. Gli eventi relativi al tempo di avvio non sono supportati utilizzando simpleperf. Tuttavia, potresti comunque essere in grado di riavviare il servizio per attivare l'evento.
Acquisire la catena di chiamate
Il primo passaggio consiste nel registrare l'evento utilizzando simpleperf record:
adb shell -t "cd /data/local/tmp && su root simpleperf record -a -g -e avc:selinux_audited"
Quindi dovrebbe essere attivato l'evento che ha causato il rifiuto. Dopodiché, la registrazione
deve essere interrotta. In questo esempio, utilizzando Ctrl-c, il campione dovrebbe essere stato acquisito:
^Csimpleperf I cmd_record.cpp:751] Samples recorded: 1. Samples lost: 0.
Infine, simpleperf report può essere utilizzato per ispezionare lo stack trace acquisito.
Ad esempio:
adb shell -t "cd /data/local/tmp && su root simpleperf report -g --full-callgraph"
[...]
Children Self Command Pid Tid Shared Object Symbol
100.00% 0.00% dmesg 3318 3318 /apex/com.android.runtime/lib64/bionic/libc.so __libc_init
|
-- __libc_init
|
-- main
toybox_main
toy_exec_which
dmesg_main
klogctl
entry_SYSCALL_64_after_hwframe
do_syscall_64
__x64_sys_syslog
do_syslog
selinux_syslog
slow_avc_audit
common_lsm_audit
avc_audit_post_callback
avc_audit_post_callback
La catena di chiamate sopra riportata è una catena di chiamate unificata del kernel e dello spazio utente. Ti offre una visione migliore del flusso del codice avviando la traccia dallo spazio utente fino al kernel in cui avviene la negazione. Per maggiori informazioni su simpleperf, consulta la
documentazione di riferimento sui comandi Simpleperf Executable
Passare a modalità permissiva
L'applicazione di SELinux può essere disabilitata con adb sulle build userdebug o eng. Per farlo,
prima imposta ADB su root eseguendo adb root. Quindi, per disattivare l'applicazione di SELinux, esegui:
adb shell setenforce 0
In alternativa, nella riga di comando del kernel (durante l'inizializzazione iniziale del dispositivo):
androidboot.selinux=permissiveandroidboot.selinux=enforcing
Oppure tramite bootconfig in Android 12:
androidboot.selinux=permissiveandroidboot.selinux=enforcing
Utilizzare audit2allow
Lo strumento audit2allow prende i rifiuti dmesg e
li converte in istruzioni del criterio SELinux corrispondenti. Di conseguenza, può
accelerare notevolmente lo sviluppo di SELinux.
Per utilizzarlo, esegui:
adb pull /sys/fs/selinux/policyadb logcat -b events -d | audit2allow -p policy
Tuttavia, è necessario esaminare attentamente ogni potenziale aggiunta per verificare che non siano presenti autorizzazioni eccessive. Ad esempio, se fornisci a audit2allow il divieto rmt_storage mostrato in precedenza, il risultato è la seguente istruzione del criterio SELinux suggerita:
#============= shell ==============
allow shell kernel:security setenforce;
#============= rmt ==============
allow rmt kmem_device:chr_file { read write };
Questo concederebbe a rmt la possibilità di scrivere la memoria del kernel, un evidente problema 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 del target, nonché incorporare le macro appropriate per ottenere un criterio valido. A volte il rifiuto esaminato non dovrebbe comportare alcuna modifica alle norme, ma l'app in questione dovrebbe essere modificata.