6 votes

Comment rendre persistantes les règles injectées par SELinux sans déballer le boot.img ?

Je travaille sur une application qui nécessite un accès Root et j'ai un appareil qui est rooté mais pas avec Magisk. Cet appareil a seulement adb shell Racine disponible. J'ai donc besoin d'une alternative pour appeler la fonctionnalité requise sans l'utilisation de Magisk ou d'autres outils. Je l'ai fait en plaçant mon exécutable dans le répertoire système et en le lançant comme un démon. Ce démon a besoin d'un accès à un emplacement qui est restreint par les politiques SELinux.

J'ai injecté la politique requise avec les commandes suivantes :

    sepolicy-inject -s init -t su -c process -p transition -l
    sepolicy-inject -s su -t system_file -c file -p entrypoint -l
    sepolicy-inject -s init -t su -c process -p rlimitinh -l
    sepolicy-inject -s init -t su -c process -p siginh -l
    sepolicy-inject -s su -t shell_exec -c file -p read -l
    sepolicy-inject -s su -t shell_exec -c file -p execute -l
    sepolicy-inject -s su -t shell_exec -c file -p getattr  -l
    sepolicy-inject -s su -t vendor_toolbox_exec -c file -p execute_no_trans -l
    sepolicy-inject -s init -t su -c process -p noatsecure -l
    sepolicy-inject -s su -t toolbox_exec -c file -p getattr -l
    sepolicy-inject -s su -t toolbox_exec -c file -p execute -l
    sepolicy-inject -s su -t system_file -c file -p execute_no_trans -l
    sepolicy-inject -s su -t storage_file -c dir -p search -l
    sepolicy-inject -s su -t storage_file -c lnk_file -p read -l
    sepolicy-inject -s su -t tmpfs -c dir -p search -l
    sepolicy-inject -s su -t mnt_user_file -c dir -p search -l
    sepolicy-inject -s su -t mnt_user_file -c lnk_file -p read -l
    sepolicy-inject -s su -t sdcardfs -c dir -p search -l
    sepolicy-inject -s su -t sdcardfs -c file -p append -l
    sepolicy-inject -s su -t toolbox_exec -c file -p read -l
    sepolicy-inject -s su -t toolbox_exec -c file -p open -l
    sepolicy-inject -s su -t sdcardfs -c file -p read -l
    sepolicy-inject -s su -t sdcardfs -c file -p write -l
    sepolicy-inject -s su -t sdcardfs -c file -p open -l
    sepolicy-inject -s su -t media_rw_data_file -c file -p read -l
    sepolicy-inject -s su -t media_rw_data_file -c file -p write -l
    sepolicy-inject -s su -t media_rw_data_file -c file -p open -l
    sepolicy-inject -s su -t media_rw_data_file -c file -p append -l

Le problème est qu'ils ne sont pas persistants après un redémarrage. Je sais que je peux extraire boot.img et ramdisk, remplacer /sepolicy par un nouveau fichier de politique copié depuis /sys/fs/selinux/policy, ré-emballer boot.img et flasher à nouveau.

Je veux le faire sans reflasher boot.img . Existe-t-il un moyen d'exécuter les commandes ci-dessus après qu'Android ait fini de générer les fichiers SELinux ?

J'ai essayé les fichiers rc suivants :

#/etc/init/custom.rc

# define service, use executable here if script not needed
service custom /system/bin/custom.sh

    # don't start unless explicitly asked to
    disabled

    # Use `seclabel u:r:magisk:s0` to run with unrestricted SELinux context to avoid avc denials
    # can also use "u:r:su:s0" on userdebug / eng builds if no Magisk
    # it's required if SELinux is enforcing and service needs access
    # to some system resources not allowed by default sepolicy
    seclabel u:r:su:s0

# start the service when boot is completed
on property:sys.boot_completed=1
    sepolicy-inject -s init -t su -c process -p transition -l
    sepolicy-inject -s su -t system_file -c file -p entrypoint -l
    sepolicy-inject -s init -t su -c process -p rlimitinh -l
    sepolicy-inject -s init -t su -c process -p siginh -l
    sepolicy-inject -s su -t shell_exec -c file -p read -l
    sepolicy-inject -s su -t shell_exec -c file -p execute -l
    sepolicy-inject -s su -t shell_exec -c file -p getattr  -l
    sepolicy-inject -s su -t vendor_toolbox_exec -c file -p execute_no_trans -l
    sepolicy-inject -s init -t su -c process -p noatsecure -l
    sepolicy-inject -s su -t toolbox_exec -c file -p getattr -l
    sepolicy-inject -s su -t toolbox_exec -c file -p execute -l
    sepolicy-inject -s su -t system_file -c file -p execute_no_trans -l
    sepolicy-inject -s su -t storage_file -c dir -p search -l
    sepolicy-inject -s su -t storage_file -c lnk_file -p read -l
    sepolicy-inject -s su -t tmpfs -c dir -p search -l
    sepolicy-inject -s su -t mnt_user_file -c dir -p search -l
    sepolicy-inject -s su -t mnt_user_file -c lnk_file -p read -l
    sepolicy-inject -s su -t sdcardfs -c dir -p search -l
    sepolicy-inject -s su -t sdcardfs -c file -p append -l
    sepolicy-inject -s su -t toolbox_exec -c file -p read -l
    sepolicy-inject -s su -t toolbox_exec -c file -p open -l
    sepolicy-inject -s su -t sdcardfs -c file -p read -l
    sepolicy-inject -s su -t sdcardfs -c file -p write -l
    sepolicy-inject -s su -t sdcardfs -c file -p open -l
    sepolicy-inject -s su -t media_rw_data_file -c file -p read -l
    sepolicy-inject -s su -t media_rw_data_file -c file -p write -l
    sepolicy-inject -s su -t media_rw_data_file -c file -p open -l
    sepolicy-inject -s su -t media_rw_data_file -c file -p append -l
    start custom

mais cela ne fonctionne pas car je pense qu'Android génère des fichiers SELinux après que mon service personnalisé ait été déclenché.

J'ai également essayé les commandes ci-dessus sur onrestart de l'option init service mais a échoué.

Une suggestion ?

4voto

Irfan Latif Points 16863

El init que vous avez défini n'injectera pas de règles de politique SELinux pour deux raisons :

  • La syntaxe de sepolicy-inject Les commandes sont incomplètes ; .rc ne sont pas des scripts shell. Le site syntaxe correcte serait :

    #/etc/init/custom.rc
    
    ...
    
    on property:sys.boot_completed=1
        exec - -- /system/bin/sepolicy-inject -s init -t su -c process -p transition -l
    
    ...
  • Ceci exécutera la déclaration avec le contexte u:r:init.s0 . Mais modifier la politique SELinux nécessite une autorisation load_policy c'est-à-dire que vous devez injecter la règle sepolicy-inject -s init -t kernel -c security -p load_policy -l qui, une fois de plus, ne sera pas autorisé à init . Lire Quel contexte de sepolicy permettra à tout autre contexte d'y accéder ? pour savoir comment SELinux est appliqué sur Android.

Donc vous êtes dans la même la poule ou l'œuf situation que vous étiez au début de votre question précédente . La politique SELinux ne peut être modifiée qu'avec le contexte u:r:su:s0 qui n'est disponible que par l'intermédiaire de adb shell en userdebug construit des ROMs. Vous pouvez aussi Rooter l'appareil, par exemple avec Magisk, ou remplacer la ROM par une autre. /sepolicy dans boot.img .

NOTE : Vous n'avez pas besoin de définir des règles comme sepolicy-inject -s su ... como u:r:su:s0 est déjà permissive set en matière de politique.

sepolicy Emplacement des fichiers :

Sur les versions Android antérieures à Treble, il y a deux emplacements possibles défini pour sepolicy fichier :

/sepolicy
/data/security/current/sepolicy

Comme indiqué aquí :

Le processus d'initialisation / de rechargement d'Android vérifiera d'abord la présence de ce fichier à l'emplacement suivant : /data/security/current/sepolicy . Si ce n'est pas le cas, vérifiez le répertoire racine : /sepolicy .

Cependant sepolicy est chargé par init au tout début du processus de démarrage lorsque /data n'est pas monté. Comme indiqué aquí :

Comme seul le système de fichiers racine est monté, il choisit /sepolicy en ce moment. L'autre voie est celle des rechargements dynamiques de la politique au moment de l'exécution.

Donc, au départ /sepolicy est chargé à coup sûr. Mais vous pouvez mettre des sepolicy à d'autres endroits pour voir si la politique précédente est (ou pourrait être) écrasée à un stade ultérieur du démarrage. Vous devrez peut-être aussi copier d'autres fichiers ; ce poste pourrait être utile. Je n'ai jamais essayé ça.

Sur Oreo+, une politique monolithique est chargée à partir de /sepolicy si l'appareil n'est pas un appareil Treble (ou si Magisk corrigé init à la charge de force /sepolicy ). Sur les appareils de type Treble /system , /vendor y /odm sont montés par le noyau avant de démarrer init comme configuré dans DTB. Ici, une politique de fractionnement précompilée est chargée à partir de /vendor/etc/selinux/precompiled_sepolicy s'il correspond à /system ou la politique est construite à partir de .cil fichiers dans /system/etc/selinux y /vendor/etc/selinux avant le chargement. Voir les détails aquí .

Dans les deux cas, les choses sont beaucoup plus compliquées à essayer que le simple remplacement de l'appareil. /sepolicy dans boot.img ce qui n'est pas un gros problème à mon avis. Vous pouvez dd une sauvegarde de votre original boot.img à /sdcard qui peut être restauré en quelques secondes à tout moment. Cependant, le chargeur de démarrage doit être déverrouillé pour démarrer un système modifié. boot.img .
Veuillez noter que sur les appareils avec système-as-Root ( A/B ou autres) ramdisk est déplacé vers system.img . Ainsi, tous les fichiers qui faisaient auparavant partie de boot.img (à l'exception du noyau et de la DTB) font désormais partie de l'UE. system partition.

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X