SuperSU n'est plus activement développé, le nouveau standard dominant est Magisk qui était à l'origine basé sur SuperSU (idées et peut-être aussi un peu de code) mais qui a maintenant pris beaucoup d'avance. Il est donc préférable d'opter pour une nouvelle solution open-source activement maintenue lorsque cela est possible. Ou si vous voulez un peu d'aventure, essayez ceci : Comment Rooter manuellement un téléphone ? .
Ma réponse à Comment fonctionne Magisk ? couvre presque tous les éléments internes de SuperSU, ainsi que quelques détails supplémentaires qui ne sont pas applicables à SuperSU. Faisons simple.
Root USER (UID 0 ):
Android est basé sur le noyau Linux qui, lorsqu'il est lancé au démarrage de l'appareil, fonctionne en tant qu'utilisateur root. Espace noyau est invisible pour nous - le espace utilisateur . init est le premier processus lancé par le noyau, comme nous pouvons le voir, il fonctionne également avec un accès Root. Il lance de nombreux services/daemons (le système d'exploitation), dont beaucoup fonctionnent également avec les privilèges Root. Enfin, lorsque tous les processus requis sont lancés, init nous ramène à un processus non-Root (non privilégié) - une coquille sur les systèmes d'exploitation Linux standard, un Application de lancement o Écran de verrouillage (qui est aussi Interface utilisateur du système app) sur Android. Root est le cher utilisateur du noyau - le Super utilisateur - identifié par U ser ID 0 . Le noyau ne l'empêche jamais de faire du mal ou du bien à quoi que ce soit sur l'appareil. Les utilisateurs non privilégiés se voient attribuer des UIDs 1 a 65534 (généralement). Android divise ces UID pour les différentes catégories d'applications et de processus comme suit aquí . Chaque processus et chaque fichier a un UID , G roup ID supplémentaire groupes et la permission mode . Ces quatre paramètres régissent la manière dont un processus accède aux autres processus et aux fichiers. L'ensemble de ce phénomène est appelé D iscretionary A ccessibilité C ontrol.
COMMENT LES APPS OBTIENNENT L'ACCÈS AUX RACINES ?
Si un processus non privilégié veut accéder à un fichier ou effectuer une action qui n'est autorisée qu'à l'utilisateur root, le premier doit passer au second. Cela se fait en exécutant un fichier (habituellement su ) qui est soit set-user-id-Root ou a setuid / segid fichier capacités . Une capacité est un sous-ensemble des autorités de l'utilisateur Root. Le fichier exécuté fait setuid syscall pour que le noyau élève l'état non privilégié à privilégié. C'est une simplification, en réalité il y a de multiples autres facteurs impliqués. Mais sur Android, les applications sont exécutées en abandonnant toutes les capacités et privilèges de manière à ce qu'elles ne puissent élever leurs privilèges d'aucune manière (à l'exception des vulnérabilités). L'application non privilégiée demande donc à un autre processus privilégié déjà en cours d'exécution d'exécuter la tâche privilégiée en son nom. Le processus privilégié est nommé daemonsu (o magiskd ) et la demande est transmise lorsqu'une application exécute des fonctions spéciales. su binaire qui interagit avec l'application SuperSU pour demander l'autorisation à l'utilisateur humain.
SELINUX :
En plus du DAC, Android fait également usage de SELinux - a M etatoire A ccessibilité C ontrol. Comme le DAC, chaque processus et chaque fichier est étiqueté avec un contexte SELinux et une politique est définie pour permettre un large éventail d'activités de contrôle. interactions entre les contextes/étiquettes. La politique ne contient pas de Super Contexte Ainsi, chaque processus (même s'il fonctionne avec l'UID 0 ) présente certaines limites. Mais daemonsu doit être exécuté dans un contexte totalement libre qui doit être défini avant que SELinux ne soit activé. enforcing (par init au tout début de la phase de démarrage) parce qu'après cela, il n'y a aucun moyen de le régler. permissive ou modifier la politique. Certains fournisseurs construisent leurs noyaux sans SECURITY_SELINUX_DEVELOP Ainsi, SELinux est appliqué par le noyau, même avant. Dans ce cas, le noyau doit être reconstruit/patché. Voir les détails dans cette réponse .
PROCESSUS D'ENRACINEMENT
Quand SuperSU.zip est flashé :
- Il corrige
/sepolicy avec un fichier entièrement permissif u:r:supersu:s0 contexte ( supersu peut être différent, je ne me rappelle pas ce que SuperSU utilisait dans les dernières versions, Magisk utilise maintenant u:r:magisk:s0 ).
- Il injecte un
init service à /init.rc qui démarre daemonsu avec UID/GID 0 et le contexte SELinux u:r:supersu:s0 après /data est monté (ou même avant).
Les deux sites sepolicy y init.rc ont fait partie de ramdisk dentro de boot.img (qui contient également le binaire du noyau), mais avec Treble, SAR y A/B Les partitions peuvent se trouver à des endroits différents. Magisk utilise donc différentes approches pour différents appareils mais le concept est le même.
Ces deux étapes peuvent également être substituées en remplaçant l'actuel /init binaire avec un init qui prend en charge le processus de démarrage, corrige sepolicy et démarre le service sur le champ avant d'exécuter l'opération. init .
D'autres choses qui sont directement liées au processus d'enracinement comprennent le déverrouillage du chargeur de démarrage, boot.img déballage/emballage, désactivation de Verified Boot ( dm-verity ) y FDE/FBE , Parcheando noyau pour démarrer différent init (ou pour désactiver les mécanismes de sécurité spécifiques au fournisseur), l'enracinement sans système, la (dé)définition des propriétés d'Android, les répertoires de montage liés, l'isolation des espaces de noms de montage, etc.
