Überprüfen Sie die Android (v30) Selinux-Richtlinie


12

Ich versuche mit selinux herauszufinden, welche Richtlinie von meinem Telefon tatsächlich durchgesetzt wird. Sie würden denken, das wäre einfach. Schließlich ist es aus Sicherheitsgründen gut zu überprüfen, ob Ihre Richtlinie den Erwartungen entspricht. Leider war dies schockierend schwierig, da A) Android anscheinend eine abgespaltene Richtlinienversion 30 verwendet und B) die Richtlinien-Toolchain einen Build-Prozess von sehr geringer Qualität zu haben scheint (viele fest codierte Pfade usw.) .).

Hier sind zwei Dinge, die ich versucht habe, die nicht funktioniert haben. Wenn ich versuche, standardmäßige Setools-Tools zu verwenden (wie sie für Fedora verpackt sind oder von AUR mit Arch Linux installiert werden können), erhalte ich Folgendes (nach dem Abrufen /sepolicyüber das Stammverzeichnis oder das Factory-Image des Telefons):

$ 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
$

Okay, das legt nahe, dass ich die Android-Version der Selinux-Bibliotheken erstellen muss. Der AOSP-Quelltextbaum enthält vorkompilierte Versionen einiger Tools, diese hängen jedoch von alten gemeinsam genutzten Bibliotheken ab, die ich nicht besitze (wie libpcre3). Wie auch immer, es ist ziemlich schockierend, wenn die einzige Möglichkeit, Ihre Sicherheitsrichtlinie zu überprüfen, darin besteht, einer binären gemeinsam genutzten Bibliothek zu vertrauen, die Sie aus dem Netz erhalten.

Also hier ist, was ich getan habe, um die Android-Selinux-Bibliotheken zu erstellen. Auf Arch musste ich ustr-selinuxvon AUR installieren , weil ustr dort einsetzt, inlinewo es jetzt benötigt wird static inline. Okay, soweit so gut. Leider ist der Build-Prozess wirklich eklatant, aber ich konnte mit folgendem Code genug davon kompilieren und installieren:

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"

Zu diesem Zeitpunkt sedispolfunktioniert eine gewöhnliche SElinux-Richtlinie (wie eine Version 29 policy.29von Fedora), zeigt mir aber immer noch nicht, was mit Android los ist:

$ ~/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
$ 

Ich habe auch versucht, die Vanille- setools3Tools gegen die Android-Bibliotheken zu kompilieren . Wiederum nicht so einfach, aber ich habe es geschafft, damit zu arbeiten:

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

Dies wird nicht vollständig erstellt, aber es wird genug von dem Quellbaum erstellt, den ich ausführen kann secmds/sesearch. Diese Art von Arbeit an einer Vanille- policy.29Datei (ich kann suchen -Aund -T, aber --allgibt mir operation not supported). Es schlägt jedoch vollständig mit einem ähnlichen Fehler fehl, wenn versucht wird, eine Android-Datei der Version 30 zu untersuchen:

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

An diesem Punkt ist mein Verstand verwirrend, dass das Tooling um etwas so Kritisches wie die Systemsicherheitsrichtlinie wirklich so schwer aufzubauen ist. Sicherlich muss ich etwas falsch machen. Hat es jemand tatsächlich geschafft, eine Android-Sicherheitsrichtlinie zu überprüfen, ohne sich auf extern verteilte gemeinsam genutzte Binärbibliotheken zu verlassen?

Ich sollte hinzufügen, dass ich auch die Techniken ausprobiert habe, die zum Neuerstellen aller vorgefertigten Tools ( ndk/build/tools/download-toolchain-sources.shund ndk/build/tools/rebuild-all-prebuilt.sh) vorgeschlagen wurden. Das download-toolchain-sources.shSkript ist derzeit jedoch fehlerhaft. Es wird versucht, alte Versionsverzeichnisse auszuchecken, die sich nicht mehr in den Repositorys befinden, und trotzdem werden anscheinend keine selinux-bezogenen Tools heruntergeladen, obwohl sie prebuilts/pythonselinux-bezogenen Code enthalten. Wieder bin ich schockiert darüber, wie unübersichtlich diese Build-Systeme sind, und denke, es muss einen einfacheren Weg geben. Die Frage, wie kann ich Tools bekommen, mit denen ich meine Android-Selinux-Richtlinie überprüfen kann?

Antworten:


8

Zunächst muss ich zugeben, dass ich Ihrer Aussage "Ich fand es schockierend schwer, dies zu tun" voll und ganz zustimme . Google hat Android hauptsächlich aus Verbrauchersicht entwickelt und nicht für Power-User. Das Ergebnis ist, dass Sie, sobald Sie etwas außerhalb der Verwendung der neuesten Facebook-App oder des Spiels mit Candy Crush tun möchten, sehr schnell wieder in das Reich von Linux zu Beginn des Jahres 2000 zurückfinden, in dem sich das Wissen eines Entwicklers ändern musste was sollen einfache einstellungen sein. Ich glaube, dass sich die Situation schnell entwickeln wird, wenn das Android-System reifer wird, aber im Moment haben wir es mit dem zu tun, was wir haben ...

Wie Sie sagten, gibt es zwei Gründe, warum es notwendig ist, Ihr eigenes SELinux-Toolset zu kompilieren:

  • Das vom System bereitgestellte Toolset ist normalerweise eine Version dahinter. Während Android-SELinux auf Policy-DB-Version 30 basiert, verarbeiten aktuelle Linux-Boxen normalerweise nur Versionen bis 29.
  • Selbst wenn es neuer wäre, würde es nicht helfen, SELinux aus Upstream-Code zu erstellen (was zumindest auf Fedora-Rechnern, die den Upstream-Empfehlungen folgen, problemlos möglich ist). Dies ermöglicht dem System, die Richtlinien-DB-Version 30 effektiv zu handhaben, wie auch immer das SELinux von Android gewesen ist Stark modifiziert (die Google-Dokumentation hebt einige Änderungen hervor), sodass der Versuch, mit Android-SELinux umzugehen, aufgrund von Syntax- und Analysefehlern fehlschlägt.

Um die SELinux-Analyse für Android fortzusetzen, müssen wir unsere Hände in den Dreck stecken ... auf die sauberste Art und Weise:

  • Zuerst werden wir eine gesunde Umgebung einrichten,
  • Sobald dies erledigt ist, werden wir die SELinux-Bibliotheken und die ersten Tools für Android kompilieren.
  • Darüber hinaus werden wir SELinux-Tools erstellen,
  • Abschließend werden einige zusätzliche Dienstprogramme hinzugefügt.

Richten Sie eine geeignete Umgebung ein

Umgebungseigenschaften

Die sauberste, möglicherweise nur zuverlässigste und empfohlene Methode besteht darin, Ihrer Android-Arbeit eine Umgebung zuzuweisen:

  • Eine virtuelle Maschine ist vollkommen in Ordnung (wenn nicht die beste Option). Verwenden Sie lieber eine VMware, da Sie Ihr Telefon über USB mit dem Gastsystem verbinden müssen. Die kostenlose Alternative Qemu scheint diese Aufgabe nicht sehr gut zu bewältigen. Ich habe es nicht mit einer anderen Virualisierungssoftware versucht.

  • Es muss sich um ein 64-Bit-System handeln, andernfalls wird der Code einfach nicht kompiliert, da Ganzzahlen die falsche Größe haben.

  • Es wird dringend empfohlen, möglicherweise obligatorisch, ein Ubuntu-System zu verwenden. Sie können stattdessen Xubuntu verwenden, wenn Sie die leichtere Desktop-Umgebung von XFCE bevorzugen. Dies ändert nicht den Kern des Systems und das verfügbare Paket und hat keine Auswirkungen auf Ihre Android-bezogene Arbeit (was auch immer ich in diesem Verfahren über Ubuntu sage, gilt auch für Xubuntu). Möglicherweise finden Sie im SELinux-Quellbaum von Android einige ReadMe-Dateien, in denen die Verwendung von Fedora empfohlen wird. Diese Dateien stammen aus dem SELinux-Projekt der vorgelagerten NSA, und ihr Inhalt muss nicht unbedingt mit Googles Android übereinstimmen.

  • Die genaue Version von Unbuntu hängt von der Android-Version ab, die Sie erstellen möchten. Für Android 6.0 wird Ubuntu 14.04 (Trusty) empfohlen. Prüfen Sie Google Anforderungen Seite für weitere Informationen.

  • Sie benötigen ausreichend Speicherplatz (mindestens 50 GB, wenn Sie nur SELinux-bezogene Untersuchungen planen, mindestens 100 GB, wenn Sie einen vollständigen Build für Android planen). CPU und Arbeitsspeicher sind weniger relevant, sie wirken sich nur auf die Zeit für einen vollständigen Build aus und haben keinen wirklichen Einfluss auf SELinux-bezogene Aufgaben.

Die Verwendung von Ubuntu hat zwei Hauptvorteile:

  • Mit dem empfohlenen System arbeiten Sie in einer bekannten und getesteten Umgebung: Systembibliotheken, Tools und Pakete haben die vom Projekt erwartete Version und Position.

  • Und genauer gesagt in unserem aktuellen Fall: Ubuntu selbst stützt sich auf AppArmor, eine SELinux-Alternative, die SELinux nicht verwendet. Die gute Nachricht ist, dass Sie daher die SELinux-Tools und -Binaries von Android systemweit installieren können, ohne die Systemzuverlässigkeit zu gefährden.

Installationsverfahren für die Umgebung

Sie können Ubuntu auf herkömmliche Weise von einer vollwertigen Live-DVD aus installieren. Eine schnellere Alternative ist jedoch die Verwendung einer Netboot-Installation (Textmodus-Installation) und die Auswahl der Desktop-Umgebung, die Sie am Ende bevorzugen. Auf diese Weise sparen Sie die anfängliche Aktualisierungszeit, indem Sie direkt die aktuelle Paketversion installieren, anstatt erst veraltete zu installieren, und dann beim ersten Start 389 ausstehende Aktualisierungen anfordern.

Das ISO für Ubuntu / Xubuntu 14.04 (gleiches ISO) Netboot-Installationsprogramm finden Sie hier .

Um die problematische Funktion "Einfache Installation" von VMware zu überspringen, sollten Sie zunächst die Option "Ich werde das Betriebssystem später installieren" auswählen .

Stellen Sie sicher, dass Sie Linux und dann Ubuntu 64-Bit als Gastbetriebssystem auswählen .

Die VM benötigt die folgenden Ressourcen:

  • Obligatorisch: Der Speicherplatz muss mindestens 40 GB betragen (die Standardeinstellung von 20 GB reicht nicht aus, der Quellcode allein benötigt mehr Speicherplatz). Es wird empfohlen, einen höheren Speicherplatz zu verwenden. Für einen vollständigen Build sind mindestens 100 GB erforderlich. Dies ist der Wert, den ich normalerweise annehme. Vergessen Sie nicht, dass diese Einstellung nur eine Höchstgrenze darstellt: Die tatsächliche Größe der VM wächst dynamisch mit den Anforderungen des Gasts.
  • Fakultativ: Erhöhen Sie den Arbeitsspeicher von 1024 auf mindestens 2048 oder höher (abhängig von Ihrer Hostkapazität, ich verwende 4096).
  • Fakultativ: Erhöhen Sie die Anzahl der Prozessorkerne von 1 auf 2 oder höher (abhängig von Ihrer Hostkapazität verwende ich 3).
  • Die CD-ROM muss auf die ISO-Installationsdatei verweisen.
  • Möglicherweise möchten Sie USB von der Standardeinstellung 1.1 auf 2.0 umschalten, da erstere möglicherweise Warnungen ausgibt, wenn Sie Ihr Gerät anschließen. Abhängig von Ihrer Nutzung können Sie auch die Kontrollkästchen "Neue USB-Geräte automatisch verbinden" und "Bluetooth-Geräte für die virtuelle Maschine freigeben " deaktivieren .
  • Abhängig von Ihrer Umgebung müssen Sie möglicherweise auch die Anzeigeeinstellungen anpassen (3D deaktivieren, Bildschirmgröße erzwingen).

Beachtung:

  • Wenn Sie sich für die Netboot-Installation entschieden haben, vergessen Sie nicht, Ihre Desktop-Umgebung ( Ubuntu-Desktop oder Xubuntu-Desktop ) auszuwählen, wenn Sie zur Softwareauswahl gelangen Bildschirm für wird nur eine minimale angezeigt!
  • Beim ersten Start verweigert auf die neueste Version zu aktualisieren: der springende Punkt hier in 14,04 zu bleiben!

Beim ersten Start können Sie als Erstes Linux-Gasttools installieren:

sudo apt-get install open-vm-tools

Dieses Paket wird beim Booten ausgelöst, seine Installation wird daher erst nach einem Gast-Neustart abgeschlossen.

Android-Quellcode abrufen

Obwohl ähnlich, hängen die Details der Prozedur vom gewählten ROM ab:

Es kann erwähnenswert sein, dass CyanogeMod in seinem Quellbaum ein Tool bündelt, mit dem Sie boot.imgDateien entpacken können. Um es anders auszudrücken, CyanogenMod bietet Ihnen ein Tool, mit dem Sie auf die sepolicyin Geräten und ROM-Archiven gespeicherte Datei zugreifen können. Googles AOSP bietet kein solches Tool. Wenn Sie also keinen anderen Grund für die Verwendung des CyanogenMod-Quellbaums haben, ist dies möglicherweise die bequemste Wahl. Andernfalls müssen Sie ihn appart installieren (was schnell und einfach ist, also keine Sorge).

Hier verfolge ich die Prozedur CyanogenMod 13.0 (Android 6.0). Erläuterungen zu den verwendeten Befehlen finden Sie auf den oben verlinkten Seiten. Bitte lesen Sie sie, das unten stehende Typoskript dient nur als Referenz.

Tipp: Während ichapt-getin diesem Beitrag verwende, um den kleinsten gemeinsamen Nenner beizubehalten und alle zufrieden zu stellen, bevorzugen Sie möglicherweise die Verwendung,aptitudeda dadurch die Abhängigkeiten besser berücksichtigt werden (beim Entfernen eines Pakets, für das einige Abhängigkeiten installiert werden mussten) werden diese Abhängigkeiten ebenfalls entfernt, wodurch Ihr System sauberer wird. AFAIK DeraptitudeBefehl muss in Ubuntu installiert sein, ist jedoch standardmäßig in Xubuntu verfügbar.

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

Jetzt haben Sie einen sauberen und fast vollständigen Quelltextbaum. Die proprietären Blobs fehlen, aber Sie benötigen sie nicht für SELinux-bezogene Aufgaben.

Trinkgeld: Abrufen der Quellen ist ein mühsamer Vorgang. Es kann sich lohnen, jetzt einen Snapshot oder eine Sicherungskopie Ihrer VM zu erstellen.

Kompilieren und installieren Sie das SELinux-Toolset und die Bibliotheken von Android

Nun beginnt der lustige Teil der Reise;)!

Bis jetzt sollte das Verfahren ziemlich einfach gewesen sein. Das Ziel bestand hauptsächlich darin, sicherzustellen, dass Sie das gleiche Umfeld haben wie ich. In diesem Fall sollte auch die Fortsetzung unkompliziert bleiben.

Unter der Haube von Google zögern Sie nicht, tiefgreifende Änderungen am Quellcode von Android zwischen den Versionen vorzunehmen. Daher sind die genauen Kompilierungsschritte mit ziemlicher Sicherheit versionsabhängig (zum Beispiel zeigt der AOSP-Master, dass das sepolicy/Verzeichnis verschoben wird ).

Ich werde zunächst meine genaue Vorgehensweise zum Kompilieren und Installieren der SElinux-Bibliotheken und -Tools von Android erläutern. Um jedoch die Relevanz dieses Beitrags im Laufe der Zeit zu erhalten, füge ich einige Hinweise zum generischen Ansatz hinzu, um die meisten Kompilierungsprobleme zu lösen.

Schritt für Schritt

Die SELinux-Bibliotheken von Android bieten die Abstraktionsschicht, mit der Software der oberen Schicht mit Android-spezifischen SELinux-Richtliniendateien umgehen kann. Wir müssen sie daher erst kompilieren und installieren (was an sich den Kern der Schwierigkeiten darstellt, bis Sie Ihren Weg gefunden haben).

Anschließend können wir SELinux-Tools erstellen und installieren. Wie wir sehen werden, müssen diese zum Glück nicht Android-spezifisch sein, sondern nur der SELinux-Bibliotheksversion entsprechen.

Dieses Verfahren wurde sowohl mit CyanogenMod- als auch mit AOSP-Quellcodebäumen getestet.

Kompilieren und installieren Sie Android SELinux-Bibliotheken und erste Tools

Installieren Sie zuerst die Abhängigkeiten:

sudo apt-get install libapol-dev libaudit-dev libdbus-glib-1-dev libgtk2.0-dev \
libustr-dev python-dev python-networkx swig xmlto

In diesem Beitrag $ANDROID_BUILD_TOPspeichert die Variable Ihren Quellspeicherort (das Verzeichnis, in dem Sie den repo syncBefehl ausgegeben haben ). Sie können den Namen beliebig ändern.

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

Standardmäßig schlägt die Kompilierung der Richtlinienkern-Utils fehl, da restoreconddas Makefile einige Bibliotheken nicht finden kann. Sie müssen dieses Makefile bearbeiten, um Pfade zu verwenden, die dynamisch von pkg-configanstelle von fest codierten Pfaden generiert wurden (verwechseln Sie Backticks nicht mit einfachen Anführungszeichen!):

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

Sie können das Makefile auch mit einem Texteditor öffnen, um sicherzustellen, dass die Änderung korrekt berücksichtigt wurde.

Und jetzt kompilieren und installieren:

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/

Achtung: Verpassen SieEMFLAGS=-fPICbeim Bauennicht dieUmgebungsvariableneinstellunglibselinux. Es wird noch kein Fehler generiert, aber im nächsten Schritt können Sie SETools nicht erstellen. Falls Sie es verpasst haben oder etwas falsch gemacht haben, geben Sie einfach einmake clean und starten Sie Ihre Kompilierung neu.

Kompilieren und installieren Sie die SELinux-Tools

SELinux-Tools werden in einer vorgefertigten Form bereitgestellt, die Folgendes umfasst:

  • Python-Skripte (und ihre Shell-Skript-Wrapper) im $ANDROID_BUILD_TOP/external/selinux/prebuilts/bin/Verzeichnis
  • Python-Pakete (einschließlich *.okompilierter Dateien) weiter unten $ANDROID_BUILD_TOP/prebuilts/python/linux-x86/2.7.5/lib/python2.7/site-packages/.

Ich hätte erwartet, dass der Quellcode dieser Tools unten verfügbar sein wird $ANDROID_BUILD_TOP/external, aber das ist es nicht. Eigentlich habe ich keinen Ort gefunden, an dem Google die genaue Version von SETools, die sie verwendet haben, freigegeben hat (zu Ihrer Information, die GPL schreibt nur vor, dass der Code freigegeben wird, wenn er geändert wurde), daher müssen wir raten und versuchen, so gut wie möglich vorzugehen .

Die Tools selbst sind Python-Skripte, eine neue Entwicklung von SETools 4 (in SETools 3 waren Befehle wie sesearchin C ausführbare Binärdateien). Die Tools selbst zeigen jedoch noch eine Version von 3.3.8:

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

Ich vermute also, dass Google eine frühe Momentaufnahme der Entwicklung von SETools 4 erstellt hat. Bis zur Beta-Version 4.0.0 stützte sich SETools auf libsepolVersion 2.4. Ab Version 4.0.0 wurde die Version 2.5 der Bibliothek verwendet, die nicht mit der Version von kompatibel ist SELinux in Android 6.0 gebündelt (Sie können versuchen, dies zu kompilieren, es wird einfach fehlschlagen).

Also scheint die klügste Wahl mit SETools 4.0.0 Beta zu gehen.

Installieren Sie zusätzliche Abhängigkeiten:

sudo apt-get install python-setuptools

Laden Sie den Quellcode herunter und extrahieren Sie ihn:

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/

Aufgrund eines Fehlers in Flex 2.5 müssen wir Folgendes -Wredundant-declsaus den Compiler-Flags entfernen :

sed -i '/-Wredundant-decls/d' ./setup.py

Und zum Schluss kompilieren und installieren Sie:

python ./setup.py build
sudo python ./setup.py install

Allgemeine Prozedur (oder "So lösen Sie sich")

Falls das oben beschriebene Verfahren in Ihrem Fall nicht funktioniert hat, finden Sie hier eine übergeordnete Ansicht, wie Sie versuchen können, Fortschritte zu erzielen.

Leider gibt es hier keine Magie (und keinen Helfer :(): Der einzige Weg, um diesen Code zum Kompilieren zu bringen, ist der klassische, aber gefürchtete zyklische "Try-and-See" -Ansatz.

Wenn Sie versuchen, das erste Mal zu kompilieren, schlägt die Kompilierung höchstwahrscheinlich fehl, da einige *.hDateien nicht gefunden wurden:

  1. Im Android- external/Verzeichnis suchen :

    find $ANDROID_BUILD_TOP/external -name filename.h
    

    Wenn Sie die angeforderte Datei finden, bedeutet dies, dass eine bestimmte Version der entsprechenden Bibliothek oder des entsprechenden Tools im Android-Quellcode enthalten ist. Sie sollten daher nicht versuchen, es vom Ubuntu-Paketsystem zu installieren, sondern die im Android-Quellcode enthaltene Version kompilieren und installieren.

    Beachten Sie, dass dies gegen den allgemeinen Rat verstößt, den Sie möglicherweise in den Foren finden: "Ihre Kompilierung schlägt fehl, weil diese Bibliothek fehlt? Installieren Sie dieses Paket, dann ist es in Ordnung!" Wenn Sie dies tun, werden Sie höchstwahrscheinlich auf ein schlimmeres Problem stoßen: Wenn eine bestimmte Version gebündelt ist, liegt dies höchstwahrscheinlich daran, dass eine bestimmte Version benötigt wird (aufgrund von Kompatibilitätsproblemen oder weil diese Version bestimmte Änderungen von Google enthält).

    Übrigens, wenn Sie sich fragen: Natürlich kann diese Bibliothek oder dieses Tool auch Abhängigkeiten aufweisen, die Fehler auslösen, weil eine *.hDatei nicht gefunden wurde, und ja, Sie sollten denselben zyklischen "Try-and-See" -Ansatz anwenden.

  2. Systemweit suchen:

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

    Wenn Sie feststellen, dass die Datei in Ihrem System an einem Standardspeicherort für gemeinsam genutzte Bibliotheken bereits vorhanden ist, bedeutet dies, dass diese Abhängigkeit wahrscheinlich bereits in Ihrer Umgebung erfüllt ist, aber das Makefile, das den Fehler ausgelöst hat, ist zu dumm, um sie zu finden.

    Wenn Sie dieses Makefile manuell direkt aufrufen, können Sie möglicherweise eine Umgebungsvariable festlegen, um dies zu beheben ( LIBDIR=/usr/lib makez. B.). Andernfalls müssen Sie das Makefile pkg-configmöglicherweise selbst ändern (der Befehl kann hilfreich sein, um fehlende Build-Parameter automatisch zu generieren). .

  3. Suche im Verpackungssystem:

    apt-cache search filename-dev
    

    Dabei steht Wobei filename-devfür den Namen der fehlenden Datei in Kleinbuchstaben, wobei die .hErweiterung durch das -devSuffix ersetzt wird (wenn Python.hbeispielsweise nicht gefunden, suchen Sie nach python-dev). Möglicherweise müssen Sie den genauen Namen anpassen, um das richtige Paket zu finden.

  4. Wenn Sie stecken bleiben und selbst eine schnelle Suche im Internet keine eindeutige Antwort lieferte, dann apt-filewerden Sie Ihr bester Freund sein. apt-fileist nicht standardmäßig installiert, Sie müssen es installieren und seine Datenbank generieren:

    sudo apt-get apt-file
    sudo apt-file update
    

    apt-fileErmöglicht die Suche nach Paketen (auch nach deinstallierten), die eine bestimmte Datei enthalten. Um zu vermeiden, dass zu viele Ergebnisse erzielt werden, empfehle ich, sie grepwie folgt zuzuordnen:

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

    Wenn das Ubuntu-Repository ein Paket enthält, das diese Datei bereitstellt, apt-filesollte es in der Lage sein, sie zu finden.

    Wenn Sie das richtige Paket gefunden haben, installieren Sie es mit apt-get install packagenamedem packagenameNamen Ihres Pakets.

Tipp: Wenn Sie etwas auf Ihrem System geschraubt, der Befehl ein Paket neu zu installieren ist diese:apt-get reinstall pkg_name. Dies funktioniert auch dann, wenn ein klassisches Entfernen und Installieren aufgrund von Abhängigkeiten nicht möglich ist (was für Systembibliotheken am wahrscheinlichsten ist).

Ergänzungswerkzeuge

In diesem Schritt sollten Sie jetzt eine saubere Umgebung haben, in der Sie die SELinux-Regeln von Android sowohl im kompilierten als auch im Quellformat untersuchen können.

Es besteht jedoch die größte Wahrscheinlichkeit, dass Sie am Ende Ihrer Untersuchung Maßnahmen ergreifen möchten. In der aktuellen Form können Sie in Ihrer Umgebung die sepolicyDatei eines Geräts nicht ändern . Tatsächlich kann diese Datei nicht einfach ersetzt werden: Sie ist Teil des Geräte-Root-Verzeichnisses und der Inhalt des Root-Verzeichnisses wird beim Booten aus einer RAM-Disk-Datei extrahiert, die wiederum im Boot-Image des Geräts gespeichert ist.

Sie vermissen also noch zwei Dinge, bevor Ihre Umgebung vollständig ist:

  • Eine Möglichkeit, auf das Startabbild des Geräts zuzugreifen und es zu ändern.
  • Eine Möglichkeit, die sepolicyDatei zu ändern .

Zum Glück sind dies genau die Themen der beiden letzten Abschnitte dieses Beitrags! :)

Ruft das Startabbild des Geräts ab und aktualisiert es

Tools zum Abrufen und Aktualisieren des Startabbilds von Geräten können für eine Vielzahl von Aufgaben verwendet werden, mit Ausnahme von Manipulationen an SELinux-Regeln. Ich habe daher eine dedizierte Antwort erstellt , bitte beziehen Sie sich darauf.

Ändern Sie die SELinux-Regeln des Geräts

Hier haben Sie zwei Hauptmöglichkeiten:

  • Erstellen Sie eine neue sepolicyDatei aus den Regeln in Ihrem Quelltextbaum (suchen Sie nach .teDateien, um sie zu finden: find $ANDROID_BUILD_TOP -name \*.teSie sind auf mehrere Verzeichnisse verteilt).
  • Ändern Sie die sepolicyaktuell vom Gerät verwendete Datei.

Sofern Sie Ihre Regeln nicht wirklich von Grund auf neu erstellen müssen, was eher eine entwicklungsbezogene Aufgabe ist und daher hier nicht zum Tragen kommt, ist die zweite Option bei weitem die sicherste, da Sie sicher sind, dass die einzigen Änderungen Ihre sind ausdrücklich gemacht.

Es gab ein Projekt, um ein Tool zu entwickeln, mit dem Sie eine sepolicyDatei in eine neu kompilierbare Form dekompilieren und Regeln dazwischen frei bearbeiten können. Dieses Projekt wurde jedoch im Proof-of-Concept-Zustand aufgegeben. Sie finden alle Informationen am Ende dieses Blog-Beitrags . Der Rest des Artikels enthält genügend Details, damit andere Interessierte die Aufgabe übernehmen können.

Der derzeit empfohlene Weg, sepolicyRegeln zu ändern , führt über einen anderen Weg: durch direktes Ändern der sepolicyBinärdatei. sepolicy-inject tool ermöglicht genau das und wird aktiv gewartet.

Beachten Sie der Vollständigkeit halber, dass es eine Gabel dieses Tools gibt. Es werden ein paar Funktionen hinzugefügt, von denen einige in der To-Do-Liste des ursprünglichen Autors aufgeführt sind (z. B. die Möglichkeit, eine Regel zu entfernen). Fragen Sie mich nicht, warum sie sich dafür entschieden haben, sich zu teilen, anstatt einen Beitrag zu leisten ...

Gehen Sie zum Kompilieren und Installieren sepolicy-injecteinfach wie folgt vor:

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/

Anwendungsbeispiel

Angenommen, Sie möchten die Autorisierung hinzufügen, die der folgenden Fehlermeldung entspricht:

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

Sie müssen das Boot-Image des Geräts abrufen und dann entpacken, um auf die sepolicyDatei zugreifen zu können .

Eine kurze Überprüfung mit sesearchzeigt, dass es (noch!) Keine Erlaubnisregel gibt:

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

Der Befehl hat keine Ausgabe.

Verwenden Sie dann den folgenden Befehl, um die erforderliche Regel hinzuzufügen (beachten Sie die Ähnlichkeit zwischen sesearchund sepolicy-injectParametern):

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

Jetzt können wir unseren sesearchBefehl zurückrufen:

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

sesearch Die Ausgabe zeigt, dass die Richtlinie korrekt aktualisiert wurde.

Sie können nun die Gerätedatei neu packen boot.imgund auf das Gerät zurückspielen. Durch Überprüfen des letzten Änderungszeitpunkts der /sepolicyDatei können Sie auf einfache Weise sicherstellen, dass auf Ihrem Gerät jetzt die neu aktualisierte sepolicyDatei ausgeführt wird.

Fazit

Sie sollten nun über eine vollständige Umgebung verfügen, in der Sie die SELinux-Richtlinien für Android-Geräte frei überprüfen und ändern können. Genießen! :)

Nebenbei bemerkt gibt es auch Tools, mit denen SELinux-Richtlinien direkt vom Gerät aus analysiert und geändert werden können .


1
nur eine Notiz - mach niemals "repo sync", es sei denn du trinkst viel Kaffee;) Benutze stattdessen "repo sync -q -f --force-sync -c" - das spart dir jede Menge Zeit und Festplattenspeicher . -q ist leise, -f und --force-sync helfen Ihnen bei temporären Netzwerkfehlern weiter, -c ruft nur den aktuellen Zweig ab. PS: Ich verwende während der Entwicklung auch "-d --prune" -Flaggen, um lokale Änderungen vollständig zu löschen und zur Manifest-Version zu wechseln.
Oleksandr

@Oleksandr: Vielen Dank für Ihre Informationen, dies ist nützlich zu wissen. Ich habe mit der -cFlagge getestet , aber keinen großen Unterschied festgestellt: Immer noch so viele Daten für den Computer zum Herunterladen (25 GB), immer noch so viel Koffein zum Trinken;). Ich bin etwas misstrauisch gegenüber der -fFlagge, da diese meines Wissens repoignoriert werden muss, wenn ein Teil des Quellcodes nicht heruntergeladen werden konnte und das Endergebnis dennoch als Erfolg gewertet wird. Ich bevorzuge es, den Status "Erfolg" für einen vollständigen Abruf zu reservieren und mich nicht in einer unbekannten Situation zu befinden, in der Dateien möglicherweise nach dem Zufallsprinzip fehlen.
WhiteWinterWolf

2

Sie sollten zuerst eine ältere Version von libsepol aus dem AOSP-Code erstellen (wie diejenige, die der 6.0-Version entspricht) und dann sepolicy-inject, dispol usw. dagegen verlinken. Dieses Rezept hat für mich bei Debian Jessie funktioniert:

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

Im Gegensatz zum sepolicy-inject, das mit dem libsepol des Systems verknüpft ist, funktioniert dieses mit / sepolicy aus dem 6.0-Image, das in der Android-SDK enthalten ist, einwandfrei:

$ 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

Für die in der Selinux-Distribution enthaltenen Tools besteht der Trick darin, sie mit demselben DESTDIR zu erstellen:

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

Vielen Dank. Dies gab mir eine Version von Sedispol, die zu funktionieren scheint, aber ich kann immer noch keine Sesearch kompilieren. Sesearch stirbt bei der Suche nach der Include-Datei <apol/policy.h>(aus einer anderen policy.hDatei). Wissen Sie, welches Modul enthält apol?
user3188445

@ user3188445: Die Datei apol/policy.hwird vom Paket bereitgestellt libapol-dev(zumindest bei Ubuntu-Systemen). Weitere Informationen finden Sie in meiner Antwort.
WhiteWinterWolf

1

An die Menschen, die mit dem Problem konfrontiert sind:

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

während der Arbeit mit AOSP-Code.

Angenommen, Ihr AOSP-Code wurde in ~ / android / source dir ausgecheckt :

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

Und jetzt können Sie das mitgelieferte Dienstprogramm audit2allow verwenden :

./external/selinux/prebuilts/bin/audit2allow

PS Auch ich möchte Kommentar Untersuchen Android (v30) Selinux-Richtlinie zu adressieren

Sesearch stirbt bei der Suche nach der Include-Datei (aus einer anderen policy.h-Datei). Wissen Sie, welches Modul apol enthält?

Das Erstellen des Selinux-Toolkits aus den Quellen https://github.com/SELinuxProject/selinux ist nicht sehr trivial (es sei denn, Sie verwenden Fedora). Unter Ubuntu müssen Sie libglib2.0-dev, libcap-ng-dev, xmlto, libsemanage1-dev, libustr-dev, libaudit-dev, libsepol1 installieren (vorausgesetzt, Sie haben bereits grundlegende Dev-Tools wie Bison und C-Compiler installiert) -dev

Aber am Ende habe ich es immer noch nicht kompiliert, weil ich https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/793155 habe und keine Ahnung habe, wie ich es beheben soll


1
Ich bin auch auf diesen glibconfig.hFehler gestoßen , den Sie am Ende Ihres Beitrags verlinken. Er wurde von restorecond's Makefile ausgelöst, weil darin falsche Pfade fest codiert waren. Sie müssen es ändern, damit Pfade mithilfe von dynamisch aufgelöst werden pkg-config. Siehe meine Antwort für weitere Details.
WhiteWinterWolf


Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.