SELinux est configuré sur default-deny, ce qui signifie que chaque accès dont il a un hook dans le noyau doit être explicitement autorisé par la stratégie. Ce signifie qu'un fichier de règles contient une grande quantité d'informations règles, types, classes, autorisations, etc. Tout savoir sur SELinux n'entrent pas dans le cadre de ce document, mais la compréhension de la façon d'écrire les règles de sécurité sont désormais essentielles lors de l'utilisation de nouveaux appareils Android. Il y a un de nombreuses informations concernant SELinux sont déjà disponibles. Reportez-vous à la section Aide documentation pour obtenir des suggestions de ressources.
Fichiers de clé
Pour activer SELinux, intégrez le dernière version Noyau Android, puis incorporez les fichiers présents system/sepolicy . Une fois compilés, ces fichiers constituent le composant de sécurité et couvrent le système d'exploitation Android en amont.
En général, vous ne devez pas modifier les fichiers system/sepolicy
directement. À la place, ajoutez ou modifiez vos propres fichiers de règles spécifiques à l'appareil dans le
/device/manufacturer/device-name/sepolicy
. Dans Android 8.0 et versions ultérieures, les modifications que vous apportez à ces fichiers doivent
n'affectent que la stratégie
dans votre répertoire de fournisseurs. Pour en savoir plus sur la séparation
sepolicy publique sur Android 8.0 et versions ultérieures, voir
Personnaliser SEPolicy sous Android
8.0 et versions ultérieures. Quelle que soit la version d'Android, vous êtes toujours en train de modifier les fichiers suivants:
Fichiers de règles
Les fichiers qui se terminent par *.te
sont des fichiers sources de règles SELinux.
définir les domaines et leurs libellés. Vous devrez peut-être créer de nouveaux fichiers de stratégie
/device/manufacturer/device-name/sepolicy
,
mais vous devez essayer de mettre à jour
les fichiers existants lorsque cela est possible.
Fichiers de contexte
Les fichiers de contexte vous permettent de spécifier des libellés pour vos objets.
file_contexts
attribue des libellés aux fichiers et est utilisé par divers de l'espace utilisateur. Lorsque vous créez des règles, créez ou mettez à jour ce fichier pour attribuer de nouveaux libellés aux fichiers. Pour appliquer un nouveaufile_contexts
, recompilez l'image du système de fichiers ou exécutezrestorecon
sur le fichier pour à modifier leur libellé. Lors des mises à niveau, les modifications apportées àfile_contexts
sont automatiquement appliquée aux partitions système et userdata dans le cadre du mise à niveau. Les modifications peuvent aussi être appliquées automatiquement lors de la mise à niveau vers d'autres des partitions en ajoutant des appelsrestorecon_recursive
à votre init.board.rc après l'installation de la partition en lecture/écriture.genfs_contexts
attribue des étiquettes aux systèmes de fichiers, commeproc
ouvfat
non compatibles avec les méthodes étendues . Cette configuration est chargée dans le cadre de la stratégie de noyau, mais les modifications peuvent ne pas prendre effet pour les nœuds de calcul intégrés, ce qui nécessite un redémarrage ou démonter et réinstaller le système de fichiers pour appliquer complètement la modification. Des étiquettes spécifiques peuvent également être attribuées à des installations spécifiques, telles quevfat
avec l'optioncontext=mount
.property_contexts
attribue des libellés aux propriétés système Android pour contrôler quels processus peuvent les définir. Cette configuration est lue parinit
au démarrage.service_contexts
attribue des étiquettes aux services de liaison Android pour contrôler quels processus peuvent ajouter (enregistrer) et trouver (rechercher) un binder référence pour le service. Cette configuration est lue parservicemanager
au démarrage.seapp_contexts
attribue des étiquettes aux processus de l'application et/data/data
. Cette configuration est lue parzygote
à chaque lancement d'appli et d'ici leinstalld
au démarrage.mac_permissions.xml
attribue un tagseinfo
aux applications en fonction de leur signature et éventuellement du nom de package. La Le tagseinfo
peut ensuite être utilisé comme clé dans le Fichierseapp_contexts
pour attribuer un libellé spécifique à toutes les applications avec cette baliseseinfo
. Cette configuration est lue parsystem_server
au démarrage.keystore2_key_contexts
attribue des étiquettes aux espaces de noms Keystore 2.0. Ces espaces de noms sont appliqués par le daemon keystore2. Keystore a toujours des espaces de noms basés sur UID/AID. Keystore 2.0 applique également sepolicy et les espaces de noms définis. Une description détaillée du format et des conventions de ce est disponible ici.
BoardConfig.mk makefile
Après avoir modifié ou ajouté des fichiers de règles et de contexte, mettez à jour votre
/device/manufacturer/device-name/BoardConfig.mk
makefile pour référencer le sous-répertoire sepolicy
et chaque nouveau fichier de stratégie.
Pour en savoir plus sur les variables BOARD_SEPOLICY
, consultez
<ph type="x-smartling-placeholder"></ph>
system/sepolicy/README
.
BOARD_SEPOLICY_DIRS += \ <root>/device/manufacturer/device-name/sepolicy BOARD_SEPOLICY_UNION += \ genfs_contexts \ file_contexts \ sepolicy.te
Une fois recompilé, SELinux est activé sur votre appareil. Vous pouvez désormais effectuer l'une des deux opérations suivantes : personnaliser vos règles SELinux en fonction de vos propres ajouts au système d'exploitation Android, comme décrit dans Personnalisation ou validation de votre la configuration existante, comme expliqué dans Validation.
Une fois les nouveaux fichiers de stratégie et les mises à jour de BoardConfig.mk en place, le nouveau les paramètres des stratégies sont automatiquement intégrés dans le fichier final de stratégie du noyau. Pour en savoir plus sur la création de sepolicy sur l'appareil, consultez Création de la règle sepolicy.
Implémentation
<ph type="x-smartling-placeholder">Pour commencer à utiliser SELinux:
- Activez SELinux dans le kernel:
CONFIG_SECURITY_SELINUX=y
- Modifiez le paramètre kernel_cmdline ou bootconfig comme suit:
ouBOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
Elle ne s'applique qu'au développement initial de la stratégie de l'appareil. Après avoir une règle d'amorçage initiale, supprimez ce paramètre pour que votre l'appareil ne l'applique pas, sinon l'outil CTS échouera.BOARD_BOOTCONFIG := androidboot.selinux=permissive
- Démarrez le système en mode permissif et observez les refus rencontrés au démarrage:
Sous Ubuntu 14.04 ou version ultérieure: Sur Ubuntu 12.04:adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
adb pull /sys/fs/selinux/policy adb logcat -b all | audit2allow -p policy
- Recherchez des avertissements ressemblant à ceux de
init: Warning! Service name needs a SELinux domain defined; please fix!
dans le résultat. Validation pour les instructions et des outils. - Identifiez les appareils et les autres nouveaux fichiers nécessitant un libellé.
- Utilisez des libellés existants ou nouveaux pour vos objets. Consultez le
*_contexts
fichiers pour afficher l'ancien libellé et utilisez la connaissance de la signification des étiquettes pour en attribuer une nouvelle. Dans l’idéal, il s'agit d'un libellé existant qui entre dans le cadre du règlement, mais il arrive un nouveau libellé sera nécessaire, et les règles d'accès à ce libellé nécessaires. Ajoutez vos libellés aux fichiers de contexte appropriés. - Identifiez les domaines/processus qui devraient disposer de leurs propres domaines de sécurité.
Vous devrez probablement rédiger une toute nouvelle règle pour chacune d'elles. Tout
les services générés à partir de
init
, par exemple, doivent avoir leur vous-même. Les commandes suivantes permettent d'afficher celles qui sont toujours en cours d'exécution (mais TOUTES nécessitent un tel traitement):
adb shell su -c ps -Z | grep init
adb shell su -c dmesg | grep 'avc: '
- Examinez
init.device.rc
pour identifier les domaines qui : n'ont pas de type de domaine. Attribuez-leur un domaine en avance dans votre de développement pour éviter d'ajouter des règles àinit
ou peut prêter à confusioninit
avec ceux qui se trouvent dans ses propres règles. - Configurez
BOARD_CONFIG.mk
pour utiliserBOARD_SEPOLICY_*
variables. Consultez le README danssystem/sepolicy
pour en savoir plus sur la configuration. - Examinez les fichiers init.device.rc et fstab.device, puis
assurez-vous que chaque utilisation de
mount
correspond à une ou qu'une optioncontext= mount
est spécifié. - Passez en revue chaque refus et créez des règles SELinux pour les gérer correctement. Voir les exemples de la section Personnalisation.
Vous devez commencer par les règles de l'AOSP, puis vous appuyer dessus pour vos propres personnalisations. Pour en savoir plus sur la stratégie de règlement plus en détail certaines de ces étapes, Écrire la règle SELinux
Cas d'utilisation
Voici des exemples spécifiques d'exploitation de failles à prendre en compte logiciels et les règles SELinux associées:
Liens symboliques : les liens symboliques se présentant sous forme de fichiers, ils sont souvent
être lus comme des fichiers, ce qui peut entraîner des exploits. Par exemple, certains rôles privilégiés
composants, tels que init
, modifient les autorisations de certains fichiers,
être parfois trop ouverte.
Les attaquants peuvent ensuite remplacer ces fichiers par des liens symboliques pour le code qu’ils contrôlent, permettant à l’attaquant d’écraser des fichiers arbitraires. Mais si vous connaissez votre l'application ne traverse jamais un lien symbolique, vous pouvez l'interdire avec SELinux.
Fichiers système : voyons la classe des fichiers système qui
ne doivent être modifiés que par le serveur système. Malgré tout, depuis le netd
,
init
et vold
s'exécutent en mode root, ils peuvent y accéder
ces fichiers système. Ainsi, si netd
est compromis, il pourrait
compromettre ces fichiers et potentiellement
le serveur système lui-même.
Avec SELinux, vous pouvez identifier ces fichiers en tant que fichiers de données du serveur système.
Par conséquent, le seul domaine disposant d'un accès en lecture/écriture est le serveur système.
Même si la sécurité du domaine netd
était compromise, il ne pourrait pas basculer les domaines vers le
domaine du serveur système et accéder à ces
fichiers système même s’il s’exécute en tant que racine.
Données d'application : la classe des fonctions doit s'exécuter en tant que racine, mais ne doit pas accéder aux données de l'application. C'est incroyablement car il est possible d'effectuer des assertions étendues (par exemple, certains domaines sans rapport aux données d'applications qui ont l'interdiction d'accéder à Internet.
setattr : pour les commandes telles que chmod
et
chown
, vous pourriez identifier l'ensemble de fichiers auquel
domaine peut effectuer setattr
. Tout ce qui dépasse
de cela pourrait être
interdit ces modifications, même par racine. Ainsi, une application
peut s'exécuter
chmod
et chown
par rapport à celles étiquetées
app_data_files
, mais pas shell_data_files
ou system_data_files
.