J'essaie de trouver quelle politique est réellement appliquée par mon téléphone à l'aide de selinux. On pourrait penser que ce serait facile. Après tout, pour la sécurité, il est bon de vérifier que votre politique correspond aux attentes. Malheureusement, j'ai trouvé cela incroyablement difficile à faire, car A) Android semble utiliser une version 30 de politique fourchue, et B) la chaîne d'outils de politique semble avoir un processus de construction de très faible qualité (beaucoup de chemins codés en dur, etc. .).

Voici deux choses que j'ai essayées et qui n'ont pas fonctionné. Si j'essaie d'utiliser des outils setools prêts à l'emploi (tels que fournis avec Fedora, ou pouvant être installés à partir d'AUR avec arch linux), alors j'obtiens ce qui suit (après avoir /sepolicyextrait du répertoire racine du téléphone ou de l'image d'usine):

$ sedispol sepolicy 
Reading policy...
libsepol.policydb_read: policydb version 30 does not match my version range 15-29
sedispol:  error(s) encountered while parsing configuration
$ sesearch --all sepolicy 
ERROR: policydb version 30 does not match my version range 15-29
ERROR: Unable to open policy sepolicy.
ERROR: Success
$

D'accord, ce qui suggère que je dois créer la version Android des bibliothèques selinux. L'arbre source AOSP est livré avec des versions précompilées de certains outils, mais celles-ci dépendent d'anciennes bibliothèques partagées que je n'ai pas (comme libpcre3). Quoi qu'il en soit, c'est assez choquant si la seule façon de vérifier votre politique de sécurité est de faire confiance à une bibliothèque partagée binaire que vous sortez du net.

Voici donc ce que j'ai fait pour créer les bibliothèques Android Selinux. Sur arch, j'ai dû installer à ustr-selinuxpartir d'AUR, car ustr utilise inlineoù il est maintenant nécessaire d'utiliser static inline. D'accord, jusqu'ici tout va bien. Malheureusement, le processus de construction est vraiment dégoûtant, mais j'ai pu en obtenir suffisamment compilé et installé avec les éléments suivants:

git clone https://android.googlesource.com/platform/external/selinux \
    android/external/selinux
export ANDROID_BUILD_TOP=$PWD/android
DESTDIR=$HOME/android_selinux
export LD_LIBRARY_PATH="$DESTDIR/lib:$DESTDIR/usr/lib"
cd android/external/selinux
sed -ie '/^LDLIBS.*(LIBDIR)/s/$/ ..\/lex.yy.o/' checkpolicy/test/Makefile
make install DESTDIR="$DESTDIR" \
     PREFIX='$(DESTDIR)/usr' \
     CFLAGS='-I$(PREFIX)/include' \
     -j20 -k
cp checkpolicy/test/dispol "$DESTDIR/usr/sbin/sedispol"
cp checkpolicy/test/dismod "$DESTDIR/usr/sbin/sedismod"

À ce stade, sedispolfonctionne une politique SElinux ordinaire (comme une version 29 policy.29de fedora), mais ne me montrera toujours pas ce qui se passe avec Android:

$ ~/android_selinux/usr/sbin/sedispol sepolicy 
Reading policy...
libsepol.avtab_read_item: more than one specifier
libsepol.avtab_read: failed on entry 457 of 5582
/home/user/android_selinux/usr/sbin/dispol:  error(s) encountered while parsing configuration
$ 

J'ai également essayé de compiler les setools3outils vanilla contre les bibliothèques Android. Encore une fois, pas si facile, mais je l'ai fait fonctionner avec:

DESTDIR=$HOME/android_selinux
export LD_LIBRARY_PATH="$DESTDIR/lib:$DESTDIR/usr/lib"
git clone https://github.com/TresysTechnology/setools3.git
cd setools3
./configure --prefix=$DESTDIR/usr --with-sepol-devel=$DESTDIR/usr CPPFLAGS="-I$DESTDIR/usr/include -L$DESTDIR/usr/lib"
make -k -j20

Cela ne se construit pas complètement, mais construit suffisamment de l'arborescence source que je peux exécuter secmds/sesearch. Ce genre de travail sur un policy.29fichier vanille (je peux rechercher -Aet -T, mais --allme donne operation not supported). Cependant, il échoue complètement avec une erreur similaire lors de l'examen d'un fichier Android version 30:

$ ./secmds/sesearch -A sepolicy 
ERROR: more than one specifier
ERROR: failed on entry 457 of 5582
ERROR: Unable to open policy sepolicy.
ERROR: Success
$ 

À ce stade, mon esprit est un peu ahurissant que l'outillage autour de quelque chose d'aussi critique que la politique de sécurité du système est vraiment difficile à construire. Je dois sûrement faire quelque chose de mal. Quelqu'un a-t-il réellement réussi à examiner une politique de sécurité Android sans s'appuyer sur des bibliothèques partagées binaires distribuées en externe?

Je dois ajouter que j'ai également essayé les techniques suggérées pour reconstruire tous les outils préconstruits ( ndk/build/tools/download-toolchain-sources.shet ndk/build/tools/rebuild-all-prebuilt.sh). Cependant, le download-toolchain-sources.shscript est actuellement cassé. Il essaie de vérifier les répertoires des anciennes versions qui ne sont plus dans les référentiels, et de toute façon il ne semble pas télécharger d'outils liés à selinux, malgré le fait qu'il prebuilts/pythoncontient du code lié à selinux. Encore une fois, je suis choqué par la cruauté de ces systèmes de construction et je pense qu'il doit y avoir un moyen plus simple. La question comment puis-je obtenir des outils qui me permettent de vérifier ma politique Android Selinux?

Tout d'abord, je dois admettre que je suis entièrement d'accord avec votre déclaration "J'ai trouvé cela scandaleusement difficile à faire" . Google a conçu Android principalement du point de vue des consommateurs, et non pour les utilisateurs expérimentés. Le résultat est que, dès que vous voulez faire quelque chose en dehors de l'utilisation de la dernière application Facebook ou jouer avec Candy Crush, vous vous retrouvez très rapidement dans le royaume de Linux au début des années 2000, quand une connaissance de type développeur était nécessaire pour changer quels devraient être les paramètres simples. Je crois que la situation évoluera rapidement à mesure que le système Android deviendra plus mature, 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 ensemble d'outils SELinux:

• Le jeu d'outils fourni par le système est généralement une version derrière. Alors que SELinux d'Android repose sur la politique DB version 30, les boîtiers Linux actuels ne gèrent généralement que la version jusqu'à 29.
• Même s'il était plus récent, cela n'aiderait pas, en fait la construction de SELinux à partir du code en amont (ce qui est facile à faire, au moins sur les machines Fedora suivant les recommandations en amont) permet efficacement au système de gérer la politique DB version 30, mais SELinux d'Android a été lourdement modifié (la documentation Google met en évidence quelques modifications), donc essayer de gérer SELinux d'Android échoue en raison d'erreurs de syntaxe et d'analyse.

Donc, pour continuer la quête d'analyse SELinux d'Android, nous devrons mettre nos mains dans la saleté ... de la manière la plus propre possible:

• Nous allons d'abord configurer un environnement sain,
• Une fois cela fait, nous compilerons les bibliothèques SELinux d'Android et les premiers outils,
• En plus, nous allons construire des outils SELinux,
• Nous terminerons en ajoutant quelques utilitaires supplémentaires.

Configurer un environnement approprié

Propriétés environnementales

La méthode la plus propre recommandée, peut-être uniquement de manière fiable, est de dédier un environnement à votre travail Android:

• Une machine virtuelle est parfaitement bien (sinon la meilleure option). Préférez utiliser un VMware car vous devrez connecter votre téléphone via USB au système invité. L'alternative gratuite Qemu ne semble pas très bien gérer une telle tâche. 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é car les nombres entiers sont de mauvaise taille.

• Il est fortement recommandé, éventuellement 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 package disponible et n'aura aucun impact sur votre travail lié à Android (tout ce que je dis à propos d'Ubuntu dans cette procédure s'applique également à Xubuntu). Vous pouvez trouver dans l'arborescence des sources SELinux d'Android des fichiers Lisez-moi 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 à 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 la page des exigences de Google pour plus d'informations.

• Vous aurez besoin de beaucoup d'espace disque (au moins 50 Go si vous prévoyez uniquement une enquête liée à SELinux, au moins 100 Go si vous prévoyez une version complète d'Android). Le processeur et la mémoire sont moins pertinents, ils n'influent que sur le temps pour une construction complète et n'auront aucun 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 bien connu et bien testé: les bibliothèques système, les outils et les packages sont à la version et à l'emplacement attendus par le projet.

• Et plus précisément 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 à l'échelle du système sans risquer d'altérer la fiabilité du système.

Procédure d'installation de l'environnement

Vous pouvez installer Ubuntu de la manière traditionnelle en commençant à partir d'un DVD live à part entière, mais une alternative plus rapide consiste à utiliser une installation netboot (installation en mode texte) et sélectionnez l'environnement de bureau que vous préférez à la fin. Cela vous permettra d'économiser le temps de mise à jour initial en installant directement la version des packages à jour au lieu d'installer d'abord les versions obsolètes, puis en demandant d'appliquer 389 mises à jour en attente au premier démarrage.

Le programme d'installation de netboot ISO pour Ubuntu / Xubuntu 14.04 (même ISO) est disponible ici .

Pour ignorer la fonction gênante «Installation facile» de VMware, il est préférable de commencer par sélectionner l' option « J'installerai le système d'exploitation plus tard» .

Assurez-vous de sélectionner Linux , puis Ubuntu 64 bits comme système d'exploitation invité.

La VM aura besoin des ressources suivantes:

• Obligatoire: l'espace disque doit être d' au moins 40 Go (les 20 Go par défaut ne seront pas suffisants, le code source à lui seul prend plus d'espace que cela), plus il est recommandé. Une version complète 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 machine virtuelle croît dynamiquement avec les demandes des invités.
• Facultative: augmenter la RAM de 1024 à au moins 2048 ou plus (dépend de la capacité de votre hôte, j'utilise 4096),
• Facultative: augmenter le nombre de cœurs de processeur de 1 à 2 ou plus (dépend de la capacité de votre hôte, j'en utilise 3).
• Le CD-Rom doit pointer vers le fichier ISO d'installation.
• Vous souhaiterez peut-être basculer USB de la valeur par défaut 1.1 à 2.0, car la première peut donner des avertissements lorsque vous connectez votre appareil. Selon votre utilisation, vous pouvez également décocher en toute sécurité "Connecter automatiquement les nouveaux périphériques USB" et "Partager les périphériques Bluetooth avec la machine virtuelle" .
• Selon votre environnement, vous devrez peut-être également modifier les paramètres d'affichage (désactiver la 3D, appliquer une taille d'écran).

Attention:

• Si vous avez choisi l'installation de netboot, n'oubliez pas de sélectionner votre environnement de bureau ( bureau Ubuntu ou bureau Xubuntu ) lorsque vous atteignez l' écran de sélection du logiciel , ou vous vous retrouverez avec un environnement textuel minimal!
• Au premier démarrage, refusez de passer à la dernière version: le but ici est de rester en 14.04!

Au premier démarrage, l'un des premiers que vous voudrez peut-être faire est d'installer les outils invités Linux:

sudo apt-get install open-vm-tools

Ce paquet met des déclencheurs au démarrage, son installation ne sera donc terminée qu'après un redémarrage invité.

Récupérer le code source Android

Bien que similaire, 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 lien "Comment construire CyanogenMod" pour obtenir des instructions adaptées à votre appareil.
• Pour AOSP, suivez la procédure qui commence ici .

Il peut être intéressant de noter que CyanogeMod regroupe dans son arborescence source un outil vous permettant de décompresser les boot.imgfichiers. Pour le dire différemment, CyanogenMod vous fournit un outil qui vous permettra d'accéder au sepolicyfichier stocké dans les appareils et les archives ROM. L'AOSP de Google ne fournit pas un tel outil, donc si vous n'avez pas d'autre impératif d'utiliser l'arborescence source de CyanogenMod peut être le choix le plus pratique, sinon vous devrez l'installer séparément (ce qui est rapide et facile à faire, donc ne vous inquiétez pas ici).

Ici, je suis la procédure CyanogenMod 13.0 (Android 6.0). Des explications sur les commandes utilisées sont disponibles sur les pages liées ci-dessus. Veuillez les lire, le texte ci-dessous n'est donné qu'à titre de référence.

Astuce: Bien que j'utiliseapt-getdans ce post pour respecter le plus petit dénominateur commun et garder tout le monde heureux, vous préférerez peut-être utiliser à laaptitudeplace car il prendra mieux en charge les dépendances (lors de la suppression d'un package qui nécessitait l'installation de certaines dépendances) , ces dépendances seront également supprimées, laissant votre système plus propre). AFAIK laaptitudecommande doit être installée dans Ubuntu mais est disponible par défaut sur 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 "[email protected]
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

Vous avez maintenant une arborescence source propre et presque complète. Les blobs propriétaires sont manquants, mais vous n'en avez pas besoin pour les tâches liées à SELinux.

Astuce: La récupération des sources est un processus fastidieux, il peut être utile de faire un instantané ou une sauvegarde de votre machine virtuelle 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 vous assurer d'avoir le même environnement que moi. Si vous le faites, la suite devrait également rester simple.

Sous le capot, Google n'hésite pas à appliquer des modifications profondes au code source d'Android entre les versions, donc les étapes de compilation exactes dépendront certainement de la version (par exemple, le maître AOSP montre que le sepolicy/répertoire sera déplacé ).

Je vais d'abord partager ma procédure exacte pour compiler et installer les bibliothèques et les outils SElinux d'Android, mais afin de garder la pertinence de ce message au fil du temps, j'ajouterai ensuite quelques notes sur l'approche générique à suivre afin de 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 couche supérieure de traiter les fichiers de politique SELinux spécifiques à Android. Nous devrons donc les calculer et les installer en premier (ce qui, en soi, représente en fait le cœur des difficultés ici, jusqu'à ce que vous ayez trouvé votre chemin).

Nous pourrons ensuite construire et installer les outils SELinux. Comme nous le verrons, heureusement, ceux-ci n'ont 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 à l'aide d'arbres de code source CyanogenMod et AOSP.

Compiler et installer les bibliothèques Android SELinux et les premiers outils

Premières dépendances d'installation:

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 post, la variable $ANDROID_BUILD_TOPstocke votre emplacement source (le répertoire où vous avez lancé la repo synccommande). N'hésitez pas à changer son nom à votre guise.

ANDROID_BUILD_TOP=~/android/system
cd $ANDROID_BUILD_TOP
source ./build/envsetup.sh

Par défaut, la compilation des principaux outils de stratégie échoue car restorecondMakefile n'est pas en mesure de localiser certaines bibliothèques. Vous devez éditer ce Makefile afin d'utiliser des chemins générés dynamiquement par pkg-configau lieu de ceux codés en dur (ne confondez pas les backticks avec des 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 compilez et installez:

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 leEMFLAGS=-fPICréglage de la variable d'environnement lors de la constructionlibselinux. Il ne générera pas encore d'erreur, mais à l'étape suivante, vous ne pourrez pas créer SETools. Dans le cas où vous l'auriez manqué ou fait quoi que ce soit de mal, émettez simplement unmake cleanet redémarrez votre compilation.

Compiler et installer les outils SELinux

Les outils SELinux sont fournis sous une forme prédéfinie qui comprend:

• Scripts Python (et leurs wrappers de scripts shell) dans le $ANDROID_BUILD_TOP/external/selinux/prebuilts/bin/répertoire
• Packages Python (y compris *.oles fichiers compilés) ci-dessous $ANDROID_BUILD_TOP/prebuilts/python/linux-x86/2.7.5/lib/python2.7/site-packages/.

Je m'attendais à ce que le code source de ces outils soit disponible ci $ANDROID_BUILD_TOP/external- dessous , mais ce n'est pas le cas. En fait, je n'ai trouvé aucun endroit où Google a partagé la version exacte de SETools qu'ils ont utilisée (FYI la GPL ne demande le partage du code que s'il a été modifié), nous devrons donc deviner et essayer de faire du mieux que nous pouvons. .

Les outils eux-mêmes sont des scripts Python, c'est une nouvelle évolution de SETools 4 (dans SETools 3, des commandes comme sesearchétaient des exécutables binaires codés en C). Cependant, les outils eux-mêmes affichent toujours une version de 3.3.8:

$ $ANDROID_BUILD_TOP/external/selinux/prebuilts/bin/sesearch --version
3.3.8

Donc, je suppose que Google a pris un instantané de développement précoce de SETools 4. Jusqu'à 4.0.0 beta SETools reposait sur libsepolversoin 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 intégré à Android 6.0 (vous pouvez essayer de le compiler, il échouera).

Donc, le choix le plus sage semble aller avec SETools 4.0.0 Beta.

Installer des 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 d' un bogue affectant Flex 2.5, nous devons supprimer -Wredundant-declsdes indicateurs 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écoller")

Dans le cas où la procédure ci-dessus n'a pas fonctionné dans votre cas, voici une vue de niveau supérieur sur la façon d'essayer de progresser.

Il n'y a malheureusement pas de magie (et pas d'aide :() ici: la seule façon d'obtenir ce code à compiler est l'approche cyclique classique mais redoutable "essayer et voir".

Essayez de compiler une première fois, il échouera très probablement car un *.hfichier est introuvable:

1. Rechercher dans le external/répertoire Android :

   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 dans le code source Android. Vous ne devriez donc pas essayer de l'installer à partir du système de packages d'Ubuntu, mais plutôt de compiler et d'installer la version fournie dans le code source 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 alors ça ira!" , en faisant cela, vous allez probablement tomber dans un problème pire: si une version spécifique est fournie, c'est 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 provoquant des erreurs en raison de la *.hnon-découverte de certains fichiers, et oui, vous devez appliquer cette même approche cyclique "essayer et voir".

2. Recherche dans tout le système:

   find / -name filename.h 2>/dev/null
   

   Si vous trouvez "manquant" que le fichier est déjà présent dans votre système dans un emplacement de bibliothèque partagée standard, cela signifie que cette dépendance est probablement déjà rencontrée dans votre environnement mais le Makefile qui a déclenché l'erreur est trop stupide pour le trouver.

   Si vous appelez directement ce Makefile manuellement, il peut être possible pour vous de définir une variable d'environnement qui le corrige ( LIBDIR=/usr/lib makepar exemple), sinon vous devrez peut-être modifier le Makefile lui-même (la pkg-configcommande peut être d'une aide précieuse pour générer automatiquement des paramètres de construction manquants) .

3. Recherche dans le système d'emballage:

   apt-cache search filename-dev
   

   Où filename-devreprésente le nom du fichier manquant en minuscules avec l' .hextension remplacée par le -devsuffixe (par exemple, s'il Python.hn'est pas trouvé, recherchez python-dev). Il peut être nécessaire de modifier le nom exact pour trouver le bon package.

4. Si vous restez coincé et que même une recherche rapide sur Internet n'a pas fourni de réponse claire, alors apt-filesera votre meilleur ami. apt-filen'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-filevous permet de rechercher des packages (même désinstallés) fournissant un fichier particulier. Pour éviter d'avoir trop de résultat, je recommande de l'associer avec grepcomme ci-dessous:

   apt-file search filename.h | grep -w filename.h
   

   S'il y a un paquet dans le référentiel d'Ubuntu fournissant ce fichier, alors il apt-filedevrait être capable de le trouver.

   Une fois que vous avez trouvé le bon package, installez-le en utilisant apt-get install packagenameoù packagenameest le nom de votre package.

Astuce: Si vous foiré quelque chose sur votre système, la commande pour réinstaller un paquet est celuici:apt-get reinstall pkg_name. Cela fonctionnera même quand une suppression / installation classique ne serait pas possible en raison de la rupture des dépendances (ce qui est très 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és et source.

Cependant, la plupart des chances sont qu'à la fin de votre enquête, vous voudrez prendre des mesures. Dans sa forme actuelle, votre environnement ne vous permettra pas de modifier le sepolicyfichier d' un périphérique . En fait, ce fichier ne peut pas être facilement remplacé: il fait partie du répertoire racine du périphérique et le contenu du répertoire racine est extrait au moment du démarrage à partir d'un fichier disque RAM, qui à son tour est 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 et de modifier l'image de démarrage de l'appareil,
• Une façon de modifier son sepolicyfichier.

Heureusement, ce sont précisément les deux dernières sections de cet article! :)

Récupérer et mettre à jour l'image de démarrage de l'appareil

Les outils pour récupérer et mettre à jour l'image de démarrage 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 , merci de vous y référer.

Modifier les règles SELinux de l'appareil

Vous avez ici deux possibilités principales:

• Construisez un nouveau sepolicyfichier à partir des règles de votre arborescence source (recherchez les .tefichiers pour les trouver:, find $ANDROID_BUILD_TOP -name \*.teils sont répartis dans plusieurs répertoires).
• Modifiez le sepolicyfichier actuellement utilisé par l'appareil.

À moins que vous n'ayez vraiment besoin de créer vos règles à partir de zéro, ce qui est plus 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 seuls changements seront ceux que vous explicite.

Il y a eu un projet pour créer un outil vous permettant de décompiler un sepolicyfichier sous une forme recompilable, permettant de modifier librement les règles entre les deux. Cependant, ce projet a été abandonné à l'état de preuve de 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 les sepolicyrègles va dans une autre direction: en modifiant directement le sepolicyfichier binaire. l' outil sepolicy-inject permet cela et est activement maintenu.

Par souci d'exhaustivité, notez qu'une fourchette de cet outil existe. Il ajoute quelques fonctionnalités, dont certaines figurent sur la liste des tâches de l'auteur d'origine (comme la possibilité de supprimer une règle), ne me demandez pas pourquoi ils ont choisi de bifurquer au lieu de contribuer ...

Pour compiler et installer sepolicy-inject, procédez simplement 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

Supposons par exemple que vous souhaitiez 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 de démarrage de l'appareil, puis la décompresser pour accéder à son sepolicyfichier.

Une vérification rapide à l'aide sesearchmontre qu'il n'y a en effet pas de règle d'autorisation (pour l'instant!):

$ 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 similitude entre les paramètres sesearchet sepolicy-inject):

sepolicy-inject -s kernel -t media_rw_data_file -c file -p read -P ./sepolicy

Maintenant, nous pouvons rappeler notre sesearchcommande:

$ sesearch -A -s kernel -t media_rw_data_file -c file -p read ./sepolicy
allow kernel media_rw_data_file:file read;
$

sesearch la sortie montre que la stratégie a été correctement mise à jour.

Vous pouvez maintenant reconditionner le boot.imgfichier de l'appareil et le flasher à nouveau sur l'appareil. La vérification de la dernière heure de modification du /sepolicyfichier est un moyen simple de s'assurer que votre appareil exécute désormais le sepolicyfichier nouvellement mis à jour .

Conclusion

Vous devriez maintenant avoir un environnement complet vous permettant d'inspecter et de modifier librement les politiques SELinux des appareils Android. Prendre plaisir! :)

En parallèle, il existe également des outils permettant d'analyser et de modifier la politique SELinux directement depuis l'appareil .

Vous devez d'abord construire une ancienne version de libsepol à partir du code AOSP (comme celle correspondant à la version 6.0), puis lier sepolicy-inject, dispol, etc. à celle-ci. Cette recette a fonctionné pour moi sur Debian Jessie:

cd /to/the/aosp/dir 
[repo init, etc]
repo sync external/selinux
cd external/selinux
git checkout android-6.0.0_r1^
cd libsepol
make
libsepol=`pwd`
cd /to/the/selinux-inject-source-dir
make LIBDIR=$libsepol

contrairement au sepolicy-inject lié au libsepol du système, celui-ci fonctionne très bien avec le / sepolicy de l'image 6.0 incluse dans le sdk android:

$ sepolicy-inject -Z shell -P /tmp/sepolicy -o /tmp/sepolicy 
libsepol.policydb_read: policydb version 30 does not match my version range 15-29
error(s) encountered while parsing configuration
Could not load policy
$ ./sepolicy-inject -Z shell -P /tmp/sepolicy -o /tmp/sepolicy 
libsepol.policydb_index_others: security:  1 users, 2 roles, 525 types, 0 bools
libsepol.policydb_index_others: security: 1 sens, 1024 cats
libsepol.policydb_index_others: security:  87 classes, 4767 rules, 0 cond rules

Pour les outils inclus dans la distribution selinux, l'astuce est de les construire avec le même DESTDIR:

cd libsepol
make DESTDIR=/some/dir install
cd ../checkpolicy
make DESTDIR=/some/dir
# here you have a working 'dispol' in the 'test' subdir

Aux personnes confrontées au problème avec:

policydb version 30 does not match my version range 15-29

tout en travaillant avec le code AOSP.

En supposant que votre code AOSP soit extrait dans le répertoire ~ / android / source :

cd ~/android/source
source build/envsetup.sh
export ANDROID_BUILD_TOP=$(pwd)

Et maintenant, vous êtes libre d'utiliser l' utilitaire d' audit2allow fourni :

./external/selinux/prebuilts/bin/audit2allow

PS Aussi, je voudrais adresser un commentaire Examiner la politique selinux android (v30)

Sesearch meurt à la recherche du fichier include (à partir d'un autre fichier policy.h). Savez-vous quel module contient apol?

Construire la boîte à outils selinux à partir de sources https://github.com/SELinuxProject/selinux n'est pas très trivial (sauf si vous utilisez Fedora). Sur Ubuntu, vous devez installer (en supposant que vous avez déjà installé des outils de développement de base comme le bison et le compilateur C) libglib2.0-dev, libcap-ng-dev, xmlto, libsemanage1-dev, libustr-dev, libaudit-dev, libsepol1 -dev

Mais à la fin, je n'ai toujours pas pu le compiler à cause de https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/793155 et je n'ai aucune idée de comment le résoudre

Vous devriez essayer d'appliquer ce correctif aux sources de libsepol, puis reconstruire progressivement tout cela. Cela a fonctionné pour moi dans le même numéro

Vous pouvez essayer d'utiliser le clone libsepol avec le patch appliqué à partir de ce dépôt https: //[email protected]/metizik/selinux_tools.git Je l'utilise pour construire dispol sous Windows, et cela fonctionne très bien pour moi (notez quand même que je suis en utilisant cygwin pour cela)

audit2allow, audit2why et sesearch sont tous rompus avec la mise à jour de la stratégie amont AOSP vers la v.30.

Vous devez appliquer les correctifs ci-dessous et reconstruire votre arborescence Android pour mettre à jour la politique db. Ces correctifs ont déjà été fusionnés avec la branche principale et disponibles à partir d'Android N.

https://android-review.googlesource.com/187140 https://android-review.googlesource.com/187111