Tout d'abord, je dois admettre que je suis entièrement d'accord avec votre "J'ai trouvé cela scandaleusement difficile à faire" déclaration. Google a conçu Android principalement du point de vue du consommateur, et non pour les utilisateurs expérimentés. Le résultat est que, dès que vous voulez faire quelque chose d'autre que d'utiliser la dernière application Facebook ou de jouer à Candy Crush, vous vous retrouvez très vite au royaume de Linux du début des années 2000, où il fallait avoir des connaissances de développeur pour modifier des paramètres qui devraient être simples. Je pense que la situation évoluera rapidement à mesure que le système Android gagnera en maturité, mais pour l'instant nous devons faire avec ce que nous avons...
Comme vous l'avez dit, il y a deux raisons pour lesquelles il est nécessaire de compiler votre propre jeu d'outils SELinux :
- Le jeu d'outils fourni par le système est généralement en retard d'une version. Alors que le SELinux d'Android s'appuie sur la version 30 de la politique DB, les boîtes Linux actuelles ne gèrent généralement que les versions jusqu'à 29.
- Même s'il était plus récent, cela n'aiderait pas, en fait, construire SELinux à partir de code amont (ce qui est facile à faire, au moins sur les machines Fedora suivant les recommandations amont) permet effectivement au système de gérer la politique DB version 30, mais le SELinux d'Android a été lourdement modifié ( Documentation Google met en évidence quelques modifications) de sorte que la tentative de gérer le SELinux d'Android échoue en raison d'erreurs de syntaxe et d'analyse.
Ainsi, pour poursuivre la quête de l'analyse SELinux d'Android, nous allons devoir mettre les mains dans le cambouis... de la manière la plus propre possible :
- Tout d'abord, nous allons configurer un environnement sain,
- Une fois cela fait, nous allons compiler les bibliothèques SELinux d'Android et les premiers outils,
- Par dessus, nous allons construire des outils SELinux,
- Nous terminerons en ajoutant quelques utilitaires supplémentaires.
Mettre en place un environnement approprié
Propriétés de l'environnement
La méthode la plus propre et la plus recommandée, voire la seule qui fonctionne de manière fiable, consiste à consacrer un environnement à votre travail sur Android :
-
Une machine virtuelle est parfaitement adaptée (même si elle n'est pas la meilleure option). Il est préférable d'utiliser une machine VMware car vous devrez connecter votre téléphone par USB au système invité. L'alternative gratuite Qemu ne semble pas gérer cette tâche très bien. Je n'ai pas essayé avec d'autres logiciels de virualisation.
-
Il devra s'agir d'un système 64 bits, sinon le code ne sera tout simplement pas compilé en raison de la taille incorrecte des entiers.
-
Il est fortement Il est recommandé, voire obligatoire, d'utiliser un système Ubuntu. N'hésitez pas à utiliser Xubuntu à la place si vous préférez l'environnement de bureau plus léger de XFCE, cela ne change pas le noyau du système et le paquetage disponible et n'aura aucun impact sur votre travail lié à Android (tout ce que je dis sur Ubuntu dans cette procédure s'applique également à Xubuntu). Vous trouverez peut-être dans l'arbre des sources SELinux d'Android des fichiers ReadMe recommandant l'utilisation de Fedora à la place, ces fichiers sont hérités du projet SELinux de la NSA en amont et leur contenu ne correspond pas nécessairement à celui d'Android de Google.
-
La version exacte d'Unbuntu à utiliser dépend de la version d'Android que vous souhaitez construire. Pour Android 6.0, Ubuntu 14.04 (Trusty) est recommandé. Consultez Page des exigences de Google pour plus d'informations.
-
Vous aurez besoin de beaucoup d'espace disque (au moins 50 Go si vous ne prévoyez que des recherches liées à SELinux, au moins 100 Go si vous prévoyez une construction complète d'Android). Le processeur et la mémoire sont moins importants, ils n'ont d'incidence que sur le temps nécessaire à une construction complète et n'auront pas d'impact réel pour les tâches liées à SELinux.
L'utilisation d'Ubuntu présente deux avantages principaux :
-
En utilisant le système recommandé, vous travaillez dans un environnement connu et bien testé : les bibliothèques, outils et paquets du système sont à la version et à l'emplacement attendus par le projet.
-
Et plus particulièrement dans notre cas actuel : Ubuntu lui-même s'appuie sur AppArmor qui est une alternative à SELinux, il n'utilise pas SELinux. La bonne nouvelle est que vous pourrez donc installer les outils et binaires SELinux d'Android sur tout le système sans risquer d'altérer la fiabilité du système.
Procédure d'installation de l'environnement
Vous pouvez installer Ubuntu de manière traditionnelle en commençant par un DVD live complet, mais une alternative plus rapide est d'utiliser une installation par le net (installation en mode texte) et de sélectionner l'environnement de bureau que vous préférez à la fin. En procédant ainsi, vous économiserez le temps de mise à jour initiale en installant directement les paquets à jour au lieu d'installer d'abord les paquets obsolètes, puis de demander d'appliquer 389 mises à jour en attente au premier démarrage.
L'ISO pour l'installateur netboot d'Ubuntu/Xubuntu 14.04 (même ISO) est le suivant disponible ici .
Pour éviter l'ennuyeuse fonction "Easy Install" de VMware, il est bon de commencer par sélectionner l'option "Easy Install". "Je vais installer le système d'exploitation plus tard" option.
Veillez à sélectionner Linux entonces Ubuntu 64 bits comme OS invité.
La VM aura besoin des ressources suivantes :
- Obligatoire : l'espace disque doit être à tout le moins 40GB (la valeur par défaut de 20 GB sera no soit suffisant, le code source seul prend plus d'espace que cela), un nombre plus élevé est recommandé. Un build complet nécessite un disque de 100 Go minimum, c'est la valeur que je prends habituellement. N'oubliez pas que ce paramètre n'est qu'une limite maximale : la taille réelle prise par la VM croît dynamiquement avec les demandes des invités.
- Facultatif : Augmentez la RAM de 1024 à au moins 2048 ou plus (cela dépend de la capacité de votre hôte, j'utilise 4096),
- Facultatif : Augmentez le nombre de cœurs de processeur de 1 à 2 ou plus (cela dépend de la capacité de votre hôte, j'utilise 3).
- Le CD-Rom doit pointer vers le fichier ISO d'installation.
- Il se peut que vous souhaitiez passer de la norme USB 1.1 par défaut à la norme 2.0, car la première peut donner des avertissements lorsque vous connectez votre appareil. En fonction de votre utilisation, vous pouvez également décocher en toute sécurité la case "Connecter automatiquement les nouveaux périphériques USB" y "Partager les dispositifs Bluetooth avec la machine virtuelle" .
- En fonction de votre environnement, vous devrez peut-être aussi modifier les paramètres d'affichage (désactiver la 3D, imposer une taille d'écran).
Attention :
- Si vous avez choisi l'installation netboot, n'oubliez pas de sélectionner votre environnement de bureau ( Bureau Ubuntu ou Bureau Xubuntu ) en atteignant le Sélection de logiciels ou vous vous retrouverez avec un environnement minimal en mode texte !
- Au premier démarrage, refuser pour passer à la dernière version : le but est de rester en 14.04 !
Lors du premier démarrage, l'une des premières choses à faire est d'installer les outils invités de Linux :
sudo apt-get install open-vm-tools
Ce paquet met des déclencheurs au démarrage, son installation ne sera donc complète qu'après un redémarrage de l'invité.
Récupérer le code source d'Android
Bien que similaires, les détails de la procédure dépendent de la ROM choisie :
- Pour CyanogenMod, recherchez votre appareil (sélectionnez d'abord le fournisseur) puis cliquez sur le bouton "Comment construire CyanogenMod" pour obtenir des instructions adaptées à votre appareil.
- Pour l'AOSP, suivez la procédure qui commence ici .
Il peut être intéressant de noter que CyanogeMod inclut dans son arbre des sources un outil permettant de décompresser boot.img dossiers. Pour le dire autrement, CyanogenMod vous fournit un outil qui vous permettra d'accéder aux sepolicy fichier stocké dans les dispositifs et les archives ROM. L'AOSP de Google ne fournit pas un tel outil, donc si vous n'avez pas d'autre impératif, utiliser l'arbre source de CyanogenMod peut être le choix le plus pratique, sinon vous devrez l'installer appart (ce qui est rapide et facile à faire, donc pas d'inquiétude ici).
Ici, je suis la procédure de CyanogenMod 13.0 (Android 6.0). Les explications sur les commandes utilisées sont disponibles sur les pages liées ci-dessus. Veuillez les lire, le tapuscrit ci-dessous est donné uniquement à titre de référence.
Conseil : Bien que j'utilise apt-get dans ce post pour s'en tenir au plus petit dénominateur commun et contenter tout le monde, vous préférerez peut-être utiliser aptitude à la place, car il s'occupera des dépendances d'une meilleure manière (lorsque vous supprimez un paquet qui nécessitait l'installation de certaines dépendances, ces dernières seront également supprimées, laissant votre système plus propre). AFAIK le aptitude doit être installée dans Ubuntu mais est disponible par défaut dans Xubuntu.
sudo apt-get install bison build-essential curl flex git gnupg gperf \
libesd0-dev liblz4-tool libncurses5-dev libsdl1.2-dev libwxgtk2.8-dev libxml2 \
libxml2-utils lzop maven openjdk-7-jdk pngcrush schedtool squashfs-tools \
xsltproc zip zlib1g-dev g++-multilib gcc-multilib lib32ncurses5-dev \
lib32readline-gplv2-dev lib32z1-dev
mkdir -p ~/bin
mkdir -p ~/android/system
PATH=~/bin:$PATH
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod u+x ~/bin/repo
cd ~/android/system/
git config --global user.name "Your Name"
git config --global user.email "you@example.com
repo init -u https://github.com/CyanogenMod/android.git -b cm-13.0
repo sync
# Coffee time: around 20GB are being downloaded, this may take several hours.
source ./build/envsetup.sh
breakfast
Maintenant vous avez un arbre des sources propre et presque complet. Les blobs propriétaires sont manquent, mais vous n'en avez pas besoin pour les tâches liées à SELinux.
Conseil : Récupérer les sources est un processus fastidieux, il peut être utile de faire un instantané ou une sauvegarde de votre VM maintenant.
Compiler et installer le jeu d'outils et les bibliothèques SELinux d'Android
Maintenant, la partie amusante du voyage commence ;) !
Jusqu'à présent, la procédure aurait dû être assez simple. Le but était principalement de s'assurer que vous avez le même environnement que moi. Si c'est le cas, la suite devrait rester simple également.
Sous le capot, Google n'hésite pas à appliquer des changements profonds au code source d'Android entre les versions, par conséquent, les étapes exactes de la compilation dépendront certainement de la version (par exemple, le master AOSP montre que l'option sepolicy/ répertoire sera déplacé ).
Je vais d'abord partager ma procédure exacte de compilation et d'installation des bibliothèques et outils SElinux d'Android, mais afin de conserver la pertinence de cet article dans le temps, j'ajouterai ensuite quelques notes sur l'approche générique à suivre pour résoudre la plupart des problèmes de compilation.
Procédure pas à pas
Les bibliothèques SELinux d'Android fournissent la couche d'abstraction qui permettra aux logiciels de la couche supérieure de traiter les fichiers de politique SELinux spécifiques à Android. Nous devrons donc d'abord les compiler et les installer (ce qui, en soi, représente le cœur des difficultés ici, jusqu'à ce que vous ayez trouvé votre chemin).
Nous serons ensuite en mesure de construire et d'installer des outils SELinux. Comme nous le verrons, ceux-ci n'ont heureusement pas besoin d'être spécifiques à Android, ils doivent seulement correspondre à la version de la bibliothèque SELinux.
Cette procédure a été testée à la fois en utilisant les arbres de code source de CyanogenMod et d'AOSP.
Compiler et installer les bibliothèques et les premiers outils SELinux d'Android
Installez d'abord les dépendances :
sudo apt-get install libapol-dev libaudit-dev libdbus-glib-1-dev libgtk2.0-dev \
libustr-dev python-dev python-networkx swig xmlto
Dans ce poste, la variable $ANDROID_BUILD_TOP stocke l'emplacement de votre source (le répertoire dans lequel vous avez émis la commande repo sync ). N'hésitez pas à changer son nom comme vous le souhaitez.
ANDROID_BUILD_TOP=~/android/system
cd $ANDROID_BUILD_TOP
source ./build/envsetup.sh
Par défaut, la compilation de policy core utils échoue à cause de restorecond Makefile ne peut pas localiser certaines bibliothèques. Vous devez éditer ce Makefile afin d'utiliser les chemins générés dynamiquement par le programme pkg-config au lieu de ceux qui sont codés en dur (ne pas confondre les backticks avec les guillemets simples !) :
sed -i 's/^CFLAGS ?= -g -Werror -Wall -W$/& `pkg-config --cflags --libs dbus-1 gtk+-2.0`/' \
$ANDROID_BUILD_TOP/external/selinux/policycoreutils/restorecond/Makefile
N'hésitez pas à ouvrir le Makefile avec un éditeur de texte pour vous assurer que la modification a été correctement prise en compte.
Et maintenant compiler et installer :
cd $ANDROID_BUILD_TOP/external/bzip2/
make -f Makefile-libbz2_so
sudo make install
cd $ANDROID_BUILD_TOP/external/libcap-ng/libcap-ng-0.7/
./configure
make
sudo make install
cd $ANDROID_BUILD_TOP/external/selinux/
make -C ./libsepol/
sudo make -C /libsepol/ install
EMFLAGS=-fPIC make -C ./libselinux/
sudo make -C ./libselinux/ install
make -C ./libsemanage/
sudo make -C ./libsemanage/ install
make
sudo make install
make swigify
sudo make install-pywrap
sudo cp ./checkpolicy/test/{dispol,dismod} /usr/bin/
Attention : Ne manquez pas le EMFLAGS=-fPIC paramètre de la variable d'environnement lors de la construction libselinux . Il ne générera pas encore d'erreur, mais à l'étape suivante, vous ne pourrez pas construire SETools. Au cas où vous l'auriez manqué ou fait quelque chose de mal, il suffit de lancer un make clean et redémarrez votre compilation.
Compiler et installer les outils SELinux
Les outils SELinux sont fournis sous une forme préconstruite qui comprend :
- Les scripts Python (et leurs enveloppes de scripts shell) au sein de l'arborescence de l'application
$ANDROID_BUILD_TOP/external/selinux/prebuilts/bin/ répertoire
- Les paquets Python (y compris
*.o fichiers compilés) ci-dessous $ANDROID_BUILD_TOP/prebuilts/python/linux-x86/2.7.5/lib/python2.7/site-packages/ .
Je me serais attendu à ce que le code source de ces outils soit disponible ci-dessous $ANDROID_BUILD_TOP/external mais ce n'est pas le cas. En fait, je n'ai pas trouvé d'endroit où Google a partagé la version exacte de SETools qu'ils ont utilisée (pour info, la GPL n'impose de partager le code que s'il a été modifié), nous devrons donc deviner et essayer de faire au mieux.
Les outils eux-mêmes sont des scripts Python, une nouvelle évolution de SETools 4 (dans SETools 3, les commandes telles que sesearch étaient des exécutables binaires codés en C). Cependant, les outils eux-mêmes montrent toujours une version de 3.3.8 :
$ $ANDROID_BUILD_TOP/external/selinux/prebuilts/bin/sesearch --version
3.3.8
Je pense donc que Google a pris un instantané des premiers développements de SETools 4. Jusqu'à la version 4.0.0 beta, SETools s'appuyait sur les éléments suivants libsepol versoin 2.4, avec la version 4.0.0 ils ont commencé à s'appuyer sur la version 2.5 de la bibliothèque qui n'est pas compatible avec la version de SELinux fournie avec Android 6.0 (vous pouvez essayer de compiler ceci, cela échouera).
Le choix le plus judicieux semble donc être SETools 4.0.0 Beta.
Installer les dépendances supplémentaires :
sudo apt-get install python-setuptools
Téléchargez et extrayez le code source :
cd ~/android/
wget https://github.com/TresysTechnology/setools/archive/4.0.0-beta.tar.gz
tar xzf 4.0.0-beta.tar.gz
cd ./setools-4.0.0-beta/
En raison de un bug en affectant Flex 2.5, nous devons supprimer -Wredundant-decls à partir des drapeaux du compilateur :
sed -i '/-Wredundant-decls/d' ./setup.py
Et enfin compiler et installer :
python ./setup.py build
sudo python ./setup.py install
Procédure générique (ou "Comment se décoincer")
Au cas où la procédure ci-dessus n'aurait pas fonctionné dans votre cas, voici une vue de plus haut niveau sur la façon d'essayer de progresser.
Malheureusement, il n'y a pas de magie (ni d'aide :( ) ici : la seule façon de faire compiler ce code est l'approche cyclique classique mais redoutée du "try-and-see".
Essayez de compiler une première fois, il est fort probable qu'il échouera à cause d'un certain *.h n'ayant pas été trouvé :
-
Cherchez dans la base de données d'Android external/ répertoire :
find $ANDROID_BUILD_TOP/external -name filename.h
Si vous trouvez le fichier demandé, cela signifie qu'une version spécifique de la bibliothèque ou de l'outil correspondant a été intégrée au code source d'Android. Vous ne devez donc pas essayer de l'installer à partir du système de paquets d'Ubuntu, mais plutôt compiler et installer la version regroupée dans le code source d'Android.
Sachez que cela va à l'encontre des conseils généraux que vous pouvez trouver sur les forums : "Votre compilation échoue à cause de cette bibliothèque manquante ? Installez ce paquet et tout ira bien !" Si une version spécifique est fournie, c'est très probablement parce qu'une version spécifique est nécessaire (en raison de problèmes de compatibilité ou parce que cette version contient des modifications spécifiques de Google).
BTW, si vous vous posez la question : bien sûr, cette bibliothèque ou cet outil peut également avoir des dépendances qui provoquent des erreurs en raison d'une certaine *.h Le fichier n'a pas été trouvé, et oui, vous devriez appliquer cette même approche cyclique "essayer et voir".
-
Recherche dans tout le système :
find / -name filename.h 2>/dev/null
Si vous trouvez que le fichier "manquant" est déjà présent dans votre système dans un emplacement standard de bibliothèque partagée, cela signifie que cette dépendance est probablement déjà satisfaite dans votre environnement mais que le Makefile qui a soulevé l'erreur est trop bête pour la trouver.
Si vous appelez manuellement et directement ce Makefile, il est possible que vous définissiez une variable d'environnement fixant ceci ( LIBDIR=/usr/lib make par exemple), sinon vous devrez peut-être modifier le fichier Makefile lui-même (la section pkg-config peut être d'une aide précieuse pour générer automatiquement les paramètres de construction manquants).
-
Recherche dans le système d'emballage :
apt-cache search filename-dev
Où filename-dev représente le nom du fichier manquant, en minuscules, avec le signe .h remplacée par l'extension -dev (par exemple, si Python.h n'est pas trouvé, recherchez python-dev ). Il peut être nécessaire de modifier le nom exact pour trouver le bon paquet.
-
Si vous restez bloqué et que même une recherche rapide sur Internet n'a pas apporté de réponse claire, alors apt-file sera votre meilleur ami. apt-file n'est pas installé par défaut, vous devez l'installer et générer sa base de données :
sudo apt-get apt-file
sudo apt-file update
apt-file vous permet de rechercher les paquets (même ceux qui sont désinstallés) fournissant un fichier particulier. Pour éviter d'avoir trop de résultat, je recommande de l'associer à grep comme ci-dessous :
apt-file search filename.h | grep -w filename.h
S'il existe un paquet dans le dépôt d'Ubuntu fournissant ce fichier, alors apt-file devrait être en mesure de le trouver.
Une fois que vous avez trouvé le bon paquet, installez-le en utilisant apt-get install packagename donde packagename est le nom de votre paquet.
Conseil : Si vous avez foiré quelque chose sur votre système, la commande pour réinstaller un paquet est celle-ci : apt-get reinstall pkg_name . Il fonctionnera même lorsqu'un retrait et une installation classiques ne seraient pas possibles en raison de la rupture des dépendances (ce qui est le plus probable pour les bibliothèques du système).
Outils supplémentaires
À cette étape, vous devriez maintenant avoir un environnement propre vous permettant d'étudier les règles SELinux d'Android à la fois dans les formats compilé et source.
Cependant, il y a de fortes chances qu'à la fin de votre enquête, vous souhaitiez prendre des mesures. Dans sa forme actuelle, votre environnement ne vous permettra pas de modifier les paramètres d'un appareil. sepolicy fichier. En fait, ce fichier ne peut pas être remplacé facilement : il fait partie du répertoire racine du périphérique, et le contenu du répertoire racine est extrait au démarrage d'un fichier du disque RAM, qui est lui-même stocké dans l'image de démarrage du périphérique.
Il vous manque donc encore deux choses avant que votre environnement ne soit complet :
- Un moyen d'accéder à l'image de démarrage du dispositif et de la modifier,
- Un moyen de modifier son
sepolicy fichier.
Heureusement, c'est précisément l'objet des deux dernières sections de ce billet ! :)
Récupérer et mettre à jour l'image de démarrage du dispositif
Les outils permettant de récupérer et de mettre à jour l'image d'amorçage des périphériques peuvent être utilisés pour une grande variété de choses, en dehors de la falsification des règles SELinux. J'ai donc créé une réponse dédiée veuillez vous y référer.
Modifier les règles SELinux du périphérique
Vous avez deux possibilités principales ici :
- Construire un nouveau
sepolicy à partir des règles de votre arbre source (recherchez .te pour les trouver : find $ANDROID_BUILD_TOP -name \*.te (ils sont répartis dans plusieurs répertoires).
- Modifiez le
sepolicy actuellement utilisé par l'appareil.
À moins que vous n'ayez vraiment besoin de construire vos règles à partir de zéro, ce qui est davantage une tâche liée au développement et donc hors de portée ici, le deuxième choix semble de loin le plus sûr, car vous êtes sûr que les seules modifications seront celles que vous avez explicitement apportées.
Il y a eu un projet pour faire un outil permettant de décompiler une sepolicy en une forme recompilable, permettant de modifier librement les règles entre les deux. Cependant ce projet a été abandonné à l'état de proof-of-concept. Vous trouverez toutes les informations à la fin de cet article de blog le reste de l'article contient suffisamment de détails pour permettre à toute autre personne intéressée de prendre le relais.
La méthode actuellement recommandée pour modifier sepolicy emprunte une autre voie : en modifiant directement les règles du sepolicy fichier binaire. sepolicy-injecter permet justement cela et est activement entretenu.
Pour être complet, notons que une fourchette de cet outil existent. Il ajoute quelques fonctionnalités, certaines d'entre elles étant sur la liste des choses à faire par l'auteur original (comme la possibilité de supprimer une règle), ne me demandez pas pourquoi ils ont choisi de forker au lieu de contribuer...
Pour compiler et installer sepolicy-inject il suffit de procéder comme suit :
cd ~/android/
git clone https://bitbucket.org/joshua_brindle/sepolicy-inject.git
cd ./sepolicy-inject/
LIBDIR=/usr/lib make
sudo cp ./sepolicy-inject /usr/bin/
Exemple de cas d'utilisation
Disons par exemple que vous voulez ajouter l'autorisation correspondant au message d'erreur suivant :
avc: denied { read } for pid=128 comm="file-storage"
path="/data/media/0/path/to/some/file"
dev="mmcblk0p28" ino=811035 scontext=u:r:kernel:s0
tcontext=u:object_r:media_rw_data_file:s0 tclass=file permissive=0
Vous devrez récupérer l'image d'amorçage du périphérique, puis la décompresser pour avoir accès à son contenu. sepolicy fichier.
Une vérification rapide en utilisant sesearch montre qu'il n'y a effectivement pas de règle d'autorisation (encore !):
$ sesearch -A -s kernel -t media_rw_data_file -c file -p read ./sepolicy
$
La commande n'a pas de sortie.
Ensuite, utilisez la commande ci-dessous pour ajouter la règle requise (notez la similarité entre sesearch y sepolicy-inject paramètres) :
sepolicy-inject -s kernel -t media_rw_data_file -c file -p read -P ./sepolicy
Maintenant, nous pouvons rappeler notre sesearch commandement :
$ sesearch -A -s kernel -t media_rw_data_file -c file -p read ./sepolicy
allow kernel media_rw_data_file:file read;
$
sesearch montre que la politique a été correctement mise à jour.
Vous pouvez maintenant remballer l'appareil boot.img et le remettre sur l'appareil. La vérification de la dernière heure de modification du fichier /sepolicy est un moyen facile de s'assurer que votre appareil exécute la nouvelle mise à jour du fichier sepolicy fichier.
Conclusion
Vous devriez maintenant avoir un environnement complet vous permettant d'inspecter et de modifier librement les politiques SELinux des dispositifs Android. Profitez-en ! :)
Par ailleurs, il existe également des outils permettant d'analyser et de modifier la politique SELinux. directement à partir de l'appareil .
