Android encourage vivement les OEM à tester minutieusement leurs implémentations SELinux. Lorsque les fabricants implémentent SELinux, ils doivent d'abord appliquer la nouvelle règle à un pool d'appareils de test.
Après avoir appliqué une nouvelle règle, assurez-vous que SELinux s'exécute dans le bon mode sur l'appareil en exécutant la commande getenforce.
Le mode SELinux global (Enforcing ou Permissive) s'affiche. À
déterminer le mode SELinux pour chaque domaine, vous devez examiner les
ou exécutez la dernière version de sepolicy-analyze avec la
l'indicateur approprié (-p), présent dans
/platform/system/sepolicy/tools/
Lire les refus
Rechercher les erreurs, qui sont acheminées en tant que journaux d'événements vers dmesg
et logcat, et sont visibles localement sur l'appareil. Les fabricants doivent examiner la sortie SELinux vers dmesg sur ces appareils et affiner les paramètres avant la publication publique en mode permissif et le passage éventuel en mode d'application. Les messages de journal SELinux contiennent avc: et peuvent donc être facilement trouvés avec grep. Il est possible de capturer l'état actuel
les journaux de refus en exécutant cat /proc/kmsg ou pour capturer les journaux de refus
du démarrage précédent en exécutant
cat /sys/fs/pstore/console-ramoops
Le taux de messages d'erreur SELinux est limité une fois le démarrage terminé afin d'éviter la surcharge
les journaux. Pour vous assurer que vous voyez tous les messages pertinents, vous pouvez désactiver cette fonctionnalité en exécutant adb shell auditctl -r 0.
Grâce à cette sortie, les fabricants peuvent facilement identifier les cas où des utilisateurs ou des composants du système ne respectent pas la stratégie SELinux. Les fabricants peuvent ensuite corriger ce mauvais comportement en modifiant le logiciel, la stratégie SELinux ou les deux.
Plus précisément, ces messages de journal indiquent quels processus échoueraient sous mode d'application et pourquoi. Voici un exemple :
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
Interprétez cette sortie comme suit :
- Le
{ connectto }ci-dessus représente l'action en cours. Avec letclassà la fin (unix_stream_socket), il indique approximativement ce qui a été fait. Dans ce cas, un élément essayait de se connecter à un socket de flux Unix. -
scontext (u:r:shell:s0)indique le contexte qui a déclenché l'action. Dans ce cas, il s'agit d'un élément exécuté en tant que shell. -
tcontext (u:r:netd:s0)indique le contexte de la cible de l'action. Dans ce cas, il s'agit d'un unix_stream_socket appartenant ànetd. - Le
comm="ping"en haut vous donne un indice supplémentaire sur ce qui était exécuté au moment de la génération du refus. Dans ce cas, c'est une très bonne astuce.
Autre exemple :
adb shell su root dmesg | grep 'avc: '
Sortie :
<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
Voici les principaux éléments de ce refus:
- Action : l'action tentée est mise en évidence entre crochets.
read writeousetenforce. - Acteur : l'entrée
scontext(contexte source) représente l'acteur, ici le daemonrmt_storage. - Objet : l'entrée
tcontext(contexte cible) représente l'objet concerné, dans ce cas kmem. - Résultat : l'entrée
tclass(classe cible) indique le type d'objet sur lequel l'action est effectuée, dans ce cas unchr_file(appareil à caractères).
Vider les piles utilisateur et du noyau
Dans certains cas, les informations contenues dans le journal des événements ne suffisent pas à identifier l'origine du refus. Il est souvent utile de collecter la chaîne d'appels, y compris le noyau et l'espace utilisateur, pour mieux comprendre pourquoi le refus s'est produit.
Les noyaux récents définissent un point de trace nommé avc:selinux_audited. Utilisez Android simpleperf pour activer ce point de trace et capturer la chaîne d'appels.
Configuration compatible
- Noyau Linux 5.10 ou version ultérieure, en particulier les branches du kernel commun Android
ligne principale
et
android12-5.10
sont pris en charge.
android12-5.4
est également prise en charge. Vous pouvez utiliser
simpleperfpour déterminer si le point de trace est défini sur votre appareil :adb root && adb shell simpleperf list | grep avc:selinux_audited. Pour d'autres versions du kernel, vous pouvez sélectionner les commits dd81662 et 30969bc. - Vous devriez pouvoir reproduire l'événement que vous déboguez. Les événements de démarrage compatibles avec simpleperf ; mais vous pourrez peut-être redémarrer le service pour déclencher l'événement.
Capturer la chaîne d'appel
La première étape consiste à enregistrer l'événement à l'aide de simpleperf record :
adb shell -t "cd /data/local/tmp && su root simpleperf record -a -g -e avc:selinux_audited"
L'événement à l'origine du refus doit alors être déclenché. L'enregistrement doit alors s'arrêter. Dans cet exemple, l'échantillon aurait dû être capturé à l'aide de Ctrl-c:
^Csimpleperf I cmd_record.cpp:751] Samples recorded: 1. Samples lost: 0.
Enfin, simpleperf report peut être utilisé pour inspecter la trace de la pile capturée.
Exemple :
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 chaîne d'appels ci-dessus est une chaîne d'appels unifiée pour le noyau et l'espace utilisateur. Il vous offre une meilleure
du flux de code en démarrant la trace de l'espace utilisateur jusqu'au noyau, où
le refus se produit. Pour en savoir plus sur simpleperf, consultez les
Documentation de référence sur les commandes exécutables Simpleperf
Passer au mode permissif
L'application de SELinux peut être désactivée avec adb sur les builds userdebug ou eng. Pour ce faire,
Commencez par faire passer ADB en mode root en exécutant adb root. Ensuite, pour désactiver l'application de SELinux, exécutez la commande suivante :
adb shell setenforce 0
Ou sur la ligne de commande du noyau (lors de l'utilisation initiale de l'appareil):
androidboot.selinux=permissiveandroidboot.selinux=enforcing
Ou via bootconfig sous Android 12:
androidboot.selinux=permissiveandroidboot.selinux=enforcing
Utiliser audit2allow
L'outil audit2allow prend les refus dmesg et
les convertit en déclarations de
politique SELinux correspondantes. À ce titre, elle peut
accélère considérablement le développement de SELinux.
Pour l'utiliser, exécutez la commande suivante :
adb pull /sys/fs/selinux/policyadb logcat -b events -d | audit2allow -p policy
Toutefois, vous devez examiner chaque ajout potentiel pour détecter les autorisations excessives. Par exemple, en alimentant audit2allow le
Le refus de rmt_storage affiché précédemment entraîne les conséquences suivantes :
Suggestion de déclaration de règle SELinux:
#============= shell ==============
allow shell kernel:security setenforce;
#============= rmt ==============
allow rmt kmem_device:chr_file { read write };
Cela donnerait à rmt la possibilité d'écrire dans la mémoire du noyau, une
une faille de sécurité flagrante. Souvent, les instructions audit2allow ne sont
point de départ. Après avoir utilisé ces instructions, vous devrez peut-être modifier le domaine source et le libellé de la cible, ainsi qu'intégrer les macros appropriées pour obtenir une bonne stratégie. Parfois, le déni examiné
n'entraîner aucune modification des règles ; plutôt que l'application incriminée
doit être modifiée.