Puisque Android est basé sur le noyau Linux, obtenir un accès Root en exécutant /system/xbin/su - comme on peut le faire sur un système Linux - ça marchait dans le bon vieux temps mais plus maintenant. L'histoire est un peu tordue.
QU'EST-CE QUE LE SUID ?
Une chose spéciale à propos de /system/xbin/su n'est pas que c'est dans /system mais la set-user-ID-root (SUID) Le bit activé sur ce binaire le rend spécial. SUID ( S et propriétaire U ser ID up on execution) est un type spécial de permission sur le noyau Linux qui accorde les permissions du propriétaire du fichier au nouveau processus plutôt que d'hériter des permissions du processus parent qui l'exécute. Puisque le propriétaire du fichier /system/xbin/su est Root (UID 0), il peut faire passer l'UID effectif du processus à 0 lors de son exécution, permettant ainsi au processus appelant d'avoir un accès Root.
Il s'agit d'une partie du contrôle d'accès discrétionnaire (DAC), l'un des éléments les plus importants de la politique de sécurité. Les fonctions de sécurité du noyau Linux .
LE CONTRÔLE D'ACCÈS OBLIGATOIRE (MAC) :
Mis en œuvre depuis KitKat, SELinux peut contrôler qui exécute su binaire, en définissant des règles de vecteur d'accès.
Sur userdebug / eng construction d'une ROM, adb shell (en exécutant su comme vous l'avez fait mentionné ) et adb daemon ( 1 ) peut faire transition ( 2 , 3 , 4 , 5 ) pour fonctionner en tant que Root avec un contexte sans restriction u:r:su:s0 ( 6 ) . Mais adbd ne peut pas être exécuté en tant que Root sur la finale user construit ( 7 , 8 ), ni le binaire su est inclus . Donc, /system/xbin/su est destiné uniquement aux développeurs pour déboguer eng ineering ou userdebug construit une ROM, pas pour l'utilisateur final ( 9 ) . La deuxième particularité est son contexte SELinux. u:object_r:su_exec:s0 .
Voir Pourquoi "adb Root" ne fait rien ? pour plus de détails.
COMMENT Android RESTRICTE L'ACCÈS au Root ?
En laissant de côté SELinux, sur la construction utilisateur d'une ROM destinée aux utilisateurs finaux, le placement de su sous /system ne donnera aucun avantage, même avec set-user-ID-root . Une application normale ne peut pas élever ses privilèges à Root en exécutant su parce que :
- En commençant par Jelly Bean Android est passé aux capacités de fichiers (une capacité est un sous-ensemble des privilèges Root) au lieu de s'appuyer sur les privilèges de l'utilisateur final.
set-user-ID type de failles de sécurité. Un mécanisme plus sûr : Capacités ambiantes a également été introduit dans Android Oreo.
- Les démons et les services du système peuvent utiliser les capacités des fichiers pour obtenir des capacités de processus (voir la rubrique Transformation des capacités pendant l'exécution ) mais les applications ne peuvent pas non plus le faire car elles fonctionnent avec l'attribut de contrôle de processus.
NO_NEW_PRIVS ensemble, en ignorant set-user-ID ainsi que des capacités de classement. SUID est également ignoré par le montage /system et /data avec nosuid pour toutes les applications.
- L'UID ne peut être commuté que si le processus appelant a SETUID/SETGID dans son Bounding set (une des 5 catégories de capacités qu'un processus peut avoir). Mais les applications Android sont faites pour fonctionner avec toutes les capacités déjà déposées dans tous les ensembles.
- À partir d'Oreo, la possibilité pour les applications de modifier l'UID/GID a été encore supprimée par bloquer certains appels système en utilisant filtres seccomp .
Le démon ADB, cependant, fonctionne avec CAP_SETUID et CAP_SETGID (pour permettre le passage à UID/GID shell ? ??). Mais adb shell trop ne peut pas nous procurer des capacités en exécutant un SUID-Root su binaire car NOROOT et NO_SETUID_FIXUP les bits de sécurité sont activés en adbd processus. Au contraire, lors d'une construction de débogage, aucune capacité n'est supprimée de l'ensemble limitatif. ( 10 ) donc l'exécution /system/xbin/su (avec set-user-ID-root ou cap_setuid,cap_setgid+ep ) nous donnerait un accès complet à la racine.
Syscalls utilisés dans ces méthodes de sandboxing : cap_set_proc , setresuid , setresgid , sys_seccomp , prctl (CAPBSET_DROP, SET_NO_NEW_PRIVS, SET_SECUREBITS, SET_SECCOMP) font toutes partie de Mini-prison .
En résumant les lignes ci-dessus, DAC et MAC ne permettraient que adb root et en exécutant /system/xbin/su de adb shell en userdebug de la ROM. Pour avoir un accès Root depuis les applications et sur user les constructions destinées à l'utilisateur final, nous devons Enraciner le téléphone comme expliqué ci-dessous.
COMMENT OBTENIR L'ACCÈS au Root sur Android ?
Donc, si nous voulons avoir des privilèges avec l'UID 0 et toutes les 38 capacités du noyau Linux, nous avons besoin d'une solution d'enracinement qui peut gérer toutes les mesures de sécurité décrites ci-dessus. Puisque la solution autonome su a cessé de fonctionner avec la sortie de Jelly Bean, une transition a été faite vers le mode su daemon .
Maintenant, sur un téléphone enraciné, un démon entièrement privilégié s'exécute dès le début du processus de démarrage (en réalité init est remplacé). Lorsqu'une application a besoin de l'accès Root, elle exécute su binaire fourni par la solution d'enracinement . Ce site su ne modifie pas l'UID/GID par lui-même, mais seulement se connecte au démon super utilisateur via un socket UNIX et demande de fournir à l'application requérante un shell Root avec toutes les capacités. Afin d'interagir avec l'utilisateur pour accorder/refuser su Pour répondre aux demandes des applications, le démon su est relié à une application qui peut afficher les invites de l'interface utilisateur. Une base de données des permissions accordées/refusées est construite par le démon su pour une utilisation future.
En outre, les refus SELinux sont également traités en définissant des règles d'autorisation de la politique SELinux lors de l'enracinement du téléphone.
Les nouvelles méthodes d'enracinement comme Magisk fonctionnent en mode sans système, c'est-à-dire sans modifier les données de l'ordinateur. /system partition. Seule la partition de démarrage - qui contient le noyau et les initramfs - est modifiée pour injecter le service du démon su et les nouvelles politiques SELiux. Un bootloader verrouillé ne démarrera pas les partitions modifiées. boot.img donc le bootloader doit être déverrouillé. Pour plus de détails à ce sujet, voir Déverrouillage du Bootloader . Cependant, il y a eu quelques hacks d'enracinement qui ont fonctionné en contournant les implémentations de sécurité décrites ci-dessus sans passer par la méthode d'enracinement appropriée. La plupart de ces exploits et vulnérabilités dans Android OS ont été corrigés au fil du temps. Voici un bon rédiger sur ce sujet.
Donc, pour conclure, en plaçant su binaire sous /system ou tout autre endroit ne donnera aucun avantage.
Voir aussi Comment fonctionne Magisk ? pour plus de détails.
PS : Veuillez ignorer les nombreux liens, ils sont pour ma propre référence future.
