Esamina la politica di selinux per Android (v30)


12

Sto cercando di trovare quale politica è effettivamente applicata dal mio telefono usando selinux. Penseresti che sarebbe facile. Dopotutto, per sicurezza è bene verificare che la vostra politica soddisfi le aspettative. Sfortunatamente, l'ho trovato incredibilmente difficile da fare, perché A) Android sembra usare una politica biforcuta versione 30 e B) la toolchain politica sembra avere un processo di costruzione di qualità molto bassa (molti percorsi codificati, ecc. .).

Ecco due cose che ho provato che non hanno funzionato. Se provo ad usare strumenti setools standard (come come pacchetto per fedora, o può essere installato da AUR con arch linux), ottengo quanto segue (dopo aver /sepolicyestratto dalla directory radice del telefono o dall'immagine di fabbrica):

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

Va bene, quindi ciò suggerisce che devo costruire la versione Android delle librerie selinux. L'albero dei sorgenti di AOSP viene fornito con versioni precompilate di alcuni strumenti, ma queste dipendono da vecchie librerie condivise che non ho (come libpcre3). Ad ogni modo, è piuttosto scioccante se l'unico modo per verificare la tua politica di sicurezza è fidarti di qualche libreria binaria condivisa che esci dalla rete.

Quindi, ecco cosa ho fatto per costruire le librerie selinux di Android. Su arco, ho dovuto installare ustr-selinuxda AUR, perché ustr usa inlinedove ora è richiesto di usare static inline. Ok, finora tutto bene. Sfortunatamente, il processo di compilazione è davvero grossolano, ma sono stato in grado di ottenerne abbastanza compilato e installato con il seguente:

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"

A questo punto, sedispolfunziona una normale politica SElinux (come una versione 29 policy.29di fedora), ma ancora non mi mostra cosa sta succedendo con 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
$ 

Ho anche provato a compilare gli setools3strumenti di vaniglia contro le librerie Android. Ancora una volta, non è così facile, ma ho avuto modo di lavorare con:

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

Questo non si costruisce completamente, ma crea abbastanza dell'albero dei sorgenti che posso eseguire secmds/sesearch. Questo tipo di lavori su un policy.29file vanilla (posso cercare -Ae -T, ma --allmi dà operation not supported). Tuttavia, fallisce completamente con un errore simile quando si tenta di esaminare un file Android versione 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
$ 

A questo punto la mia mente è un po 'sbalorditiva sul fatto che la strumentazione intorno a qualcosa di così critico come la politica di sicurezza del sistema sia davvero così difficile da costruire. Sicuramente devo fare qualcosa di sbagliato. Qualcuno è effettivamente riuscito a esaminare una politica di sicurezza Android senza fare affidamento su librerie condivise binarie distribuite esternamente?

Dovrei aggiungere che ho anche provato le tecniche suggerite per ricostruire tutti gli strumenti precompilati ( ndk/build/tools/download-toolchain-sources.she ndk/build/tools/rebuild-all-prebuilt.sh). Tuttavia lo download-toolchain-sources.shscript è attualmente rotto. Cerca di controllare le directory delle vecchie versioni che non si trovano più nei repository e comunque non sembra scaricare alcun tool relativo a selinux, nonostante ciò prebuilts/pythoncontenga codice relativo a selinux. Ancora una volta, sono scioccato da quanto siano fragili questi sistemi di costruzione e penso che debba esserci un modo più semplice. La domanda come posso ottenere strumenti che mi consentono di controllare la mia politica di selinux di Android?

Risposte:


8

Prima di tutto, devo ammettere che sono pienamente d'accordo con la tua dichiarazione "Ho trovato questo lavoro incredibilmente difficile da fare" . Google ha progettato Android principalmente dal punto di vista del consumatore e non per utenti esperti. Il risultato è che, non appena vuoi fare qualcosa al di fuori dell'uso dell'ultima app di Facebook o di giocare con Candy Crush, ti ritrovi molto rapidamente nel regno di Linux dei primi anni del 2000, quando era richiesta una conoscenza simile a quella degli sviluppatori per cambiare quali dovrebbero essere le impostazioni semplici. Credo che la situazione si evolverà rapidamente man mano che il sistema Android diventa più maturo, ma per ora abbiamo a che fare con quello che abbiamo ...

Come hai detto, ci sono due motivi per cui è necessario compilare il proprio set di strumenti SELinux:

  • Il set di strumenti fornito dal sistema è in genere una versione precedente. Mentre SELinux di Android si basa sul DB delle politiche versione 30, le attuali scatole Linux di solito gestiscono solo la versione fino a 29.
  • Anche se sarebbe più recente, non sarebbe di aiuto, infatti la creazione di SELinux dal codice upstream (che è facilmente eseguibile, almeno su macchine Fedora seguendo le raccomandazioni upstream) consente efficacemente al sistema di gestire il DB di politica versione 30, tuttavia SELinux di Android è stato fortemente modificato (la documentazione di Google evidenzia alcune modifiche), quindi il tentativo di gestire SELinux di Android fallisce a causa della sintassi e degli errori di analisi.

Quindi, per continuare la ricerca di analisi SELinux su Android, dovremo mettere le mani nella sporcizia ... nel modo più pulito possibile:

  • Per prima cosa installeremo un ambiente sano,
  • Fatto ciò, compileremo le librerie SELinux di Android e i primi strumenti,
  • Inoltre, costruiremo strumenti SELinux,
  • Concluderemo aggiungendo alcune utilità supplementari.

Imposta un ambiente adeguato

Proprietà dell'ambiente

Il modo più pulito consigliato, forse forse solo in modo affidabile, è quello di dedicare un ambiente al tuo lavoro Android:

  • Una macchina virtuale va benissimo (se non l'opzione migliore). Preferisci usarne uno VMware poiché dovrai connettere il tuo telefono tramite USB al sistema guest. L'alternativa gratuita Qemu non sembra gestire molto bene tale compito. Non ho provato con altri software di virualizzazione.

  • Dovrà essere un sistema a 64 bit, altrimenti il ​​codice semplicemente non verrà compilato a causa della dimensione errata degli interi.

  • Si consiglia vivamente , possibilmente obbligatorio, di utilizzare un sistema Ubuntu. Sentiti libero di usare Xubuntu invece se preferisci l'ambiente desktop più leggero di XFCE, questo non cambia il core del sistema e il pacchetto disponibile e non avrà alcun impatto sul tuo lavoro relativo ad Android (tutto ciò che dico su Ubuntu in questa procedura si applica anche a Xubuntu). Nell'albero dei sorgenti SELinux di Android potresti trovare alcuni file Leggimi che raccomandano l'uso di Fedora, questi file sono ereditati dal progetto SELinux dell'NSA a monte e il loro contenuto non corrisponde necessariamente ad Android di Google.

  • La versione esatta di Unbuntu da utilizzare dipende dalla versione di Android che desideri creare. Per Android 6.0, si consiglia Ubuntu 14.04 (Trusty). Controlla la pagina dei requisiti di Google per ulteriori informazioni.

  • Avrai bisogno di molto spazio su disco (almeno 50 GB se pianifichi solo indagini relative a SELinux, almeno 100 GB se prevedi una build completa di Android). La CPU e la memoria sono meno rilevanti, hanno un impatto solo sul tempo per un build completo e non avranno alcun impatto reale per le attività relative a SELinux.

L'uso di Ubuntu ha due vantaggi principali:

  • Utilizzando il sistema consigliato, si lavora in un ambiente ben noto e testato: le librerie di sistema, gli strumenti e i pacchetti sono nella versione e nel percorso previsti dal progetto.

  • E più precisamente nel nostro caso attuale: Ubuntu stesso si basa su AppArmor che è un'alternativa SELinux, non utilizza SELinux. La buona notizia è che sarai quindi in grado di installare gli strumenti e i binari SELinux di Android a livello di sistema senza rischiare di alterare l'affidabilità del sistema.

Procedura di installazione dell'ambiente

Puoi installare Ubuntu in modo tradizionale partendo da un DVD live completo, ma un'alternativa più veloce è usare un'installazione netboot (installazione in modalità testo) e selezionare l'ambiente desktop che preferisci alla fine. In questo modo risparmierai il tempo di aggiornamento iniziale installando direttamente la versione aggiornata dei pacchetti anziché prima installando quelli obsoleti, quindi chiedendo di applicare 389 aggiornamenti in sospeso al primo avvio.

Il programma di installazione di netboot ISO per Ubuntu / Xubuntu 14.04 (stesso ISO) è disponibile qui .

Per saltare la fastidiosa funzione "Easy Install" di VMware, è una buona abitudine iniziare selezionando l' opzione "Installerò il sistema operativo in seguito" .

Assicurati di selezionare Linux , quindi Ubuntu 64 bit come SO guest.

La VM avrà bisogno delle risorse seguenti:

  • Obbligatorio: lo spazio su disco deve essere di almeno 40 GB (i 20 GB predefiniti non saranno sufficienti, il codice sorgente da solo occupa più spazio di quello), si consiglia un valore superiore. Una build completa richiede un minimo di 100 GB di disco, questo è il valore che di solito prendo. Non dimenticare che questa impostazione è solo un limite massimo: le dimensioni effettive prese dalla VM aumentano in modo dinamico con le richieste dell'ospite.
  • Facoltativo: aumentare la RAM da 1024 ad almeno 2048 o superiore (dipende dalla capacità dell'host, utilizzo 4096),
  • Facoltativo: aumentare il numero di core del processore da 1 a 2 o superiore (dipende dalla capacità dell'host, io uso 3).
  • Il CD-Rom deve puntare al file ISO di installazione.
  • È possibile che si desideri cambiare USB dall'impostazione predefinita 1.1 alla 2.0 in quanto la prima potrebbe fornire avvisi quando si collega il dispositivo. A seconda dell'utilizzo, puoi anche deselezionare "Connetti automaticamente nuovi dispositivi USB" e "Condividi dispositivi Bluetooth con la macchina virtuale" .
  • A seconda del proprio ambiente, potrebbe anche essere necessario modificare le impostazioni di visualizzazione (disabilitare il 3D, applicare una dimensione dello schermo).

Attenzione:

  • Se hai scelto l'installazione di netboot, non dimenticare di selezionare il tuo ambiente desktop ( desktop Ubuntu o desktop Xubuntu ) quando raggiungi la schermata di selezione del software , o finirai con un ambiente di solo testo minimo!
  • Al primo avvio, rifiuta di eseguire l'aggiornamento all'ultima versione: il punto qui è di rimanere in 14.04!

Al primo avvio, uno dei primi che potresti voler fare è installare gli strumenti guest Linux:

sudo apt-get install open-vm-tools

Questo pacchetto attiva i trigger all'avvio, pertanto l'installazione verrà completata solo dopo il riavvio del guest.

Recupera il codice sorgente Android

Sebbene simili, i dettagli della procedura dipendono dalla ROM scelta:

  • Per CyanogenMod, cerca il tuo dispositivo (seleziona prima il fornitore), quindi fai clic sul link "Come costruire CyanogenMod" per ottenere istruzioni adattate per il tuo dispositivo.
  • Per AOSP, seguire la procedura che inizia qui .

Vale la pena notare che CyanogeMod raggruppa nella sua struttura di origine uno strumento che consente di decomprimere i boot.imgfile. Per dirlo in modo diverso, CyanogenMod ti fornisce uno strumento che ti permetterà di accedere al sepolicyfile archiviato nei dispositivi e negli archivi ROM. L'AOSP di Google non fornisce tale strumento, quindi se non hai altri imperativi utilizzando l'albero dei sorgenti di CyanogenMod potrebbe essere la scelta più conveniente, altrimenti dovrai installarlo appart (che è veloce e facile da fare, quindi non preoccuparti qui).

Qui sto seguendo la procedura CyanogenMod 13.0 (Android 6.0). Spiegazione sui comandi utilizzati è disponibile nelle pagine collegate sopra. Si prega di leggerli, il dattiloscritto di seguito viene fornito solo a scopo di riferimento.

Suggerimento: Mentre utilizzoapt-getin questo post per attenermi al minimo comune denominatore e rendere tutti felici, potresti preferireaptitudeinveceutilizzarlopoiché si occuperà delle dipendenze in un modo migliore (durante la rimozione di un pacchetto che richiedeva l'installazione di alcune dipendenze , anche queste dipendenze verranno rimosse, lasciando il sistema più pulito). AFAIK ilaptitudecomando deve essere installato in Ubuntu ma è disponibile per impostazione predefinita su 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

Ora hai un albero delle fonti pulito e quasi completo. Mancano i BLOB proprietari, ma non sono necessari per le attività relative a SELinux.

Suggerimento: recuperare le fonti è un processo noioso, potrebbe valere la pena fare un'istantanea o un backup della VM ora.

Compilare e installare il set di strumenti e le librerie SELinux di Android

Ora inizia la parte divertente del viaggio;)!

Fino ad ora la procedura avrebbe dovuto essere piuttosto semplice. L'obiettivo era principalmente quello di assicurarmi che tu abbia lo stesso ambiente in cui mi trovo. Se lo fai, anche il sequel dovrebbe rimanere semplice.

Sotto il cofano, Google non esita ad applicare profonde modifiche al codice sorgente di Android tra le versioni, quindi i passaggi esatti della compilazione dipenderanno sicuramente dalla versione (ad esempio, il master AOSP mostra che la sepolicy/directory verrà spostata ).

Condividerò prima la mia esatta procedura per compilare e installare le librerie e il set di strumenti SElinux di Android, ma al fine di mantenere la pertinenza di questo post nel tempo, aggiungerò alcune note sull'approccio generico da seguire per risolvere la maggior parte dei problemi di compilazione.

Procedura dettagliata

Le librerie SELinux di Android forniscono il livello di astrazione che consentirà al software di livello superiore di gestire i file delle politiche SELinux specifici di Android. Dovremo quindi compilarli e installarli prima (che, di per sé, in realtà rappresenta il nucleo se le difficoltà qui, fino a quando non hai trovato la tua strada).

Saremo quindi in grado di costruire e installare strumenti SELinux. Come vedremo, fortunatamente questi non devono essere specifici per Android, devono solo corrispondere alla versione della libreria SELinux.

Questa procedura è stata testata sia usando gli alberi di codice sorgente CyanogenMod che AOSP.

Compilare e installare librerie e primi strumenti SELinux per Android

Dipendenze per la prima installazione:

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

In questo post la variabile $ANDROID_BUILD_TOPmemorizza la posizione di origine (la directory in cui è stato emesso il repo synccomando). Sentiti libero di cambiare il suo nome come preferisci.

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

Per impostazione predefinita, la compilazione dei programmi di utilità core non riesce a causa restoreconddel fatto che Makefile non è in grado di individuare alcune librerie. Devi modificare questo Makefile per usare percorsi generati dinamicamente pkg-configinvece di quelli hardcoded (non confondere i backtick con virgolette singole!):

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

Sentiti libero di aprire il Makefile con qualche editor di testo per assicurarti che la modifica sia stata correttamente presa in considerazione.

E ora compila e installa:

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/

Attenzione: non perdere l'EMFLAGS=-fPICimpostazione della variabile di ambiente durante la creazionelibselinux. Non genererà ancora alcun errore, ma nel passaggio successivo non sarà possibile creare SETools. Se l'hai perso o hai fatto qualcos'altro, semplicemente emetti unmake cleane riavvia la compilation.

Compilare e installare strumenti SELinux

Gli strumenti SELinux sono forniti in una forma predefinita che include:

  • Script Python (e relativi wrapper di script shell) all'interno della $ANDROID_BUILD_TOP/external/selinux/prebuilts/bin/directory
  • Pacchetti Python (inclusi *.ofile compilati) di seguito $ANDROID_BUILD_TOP/prebuilts/python/linux-x86/2.7.5/lib/python2.7/site-packages/.

Mi sarei aspettato che il codice sorgente di questi strumenti fosse disponibile di seguito $ANDROID_BUILD_TOP/external, ma non lo è. In realtà, non ho trovato alcun posto in cui Google condividesse la versione esatta di SETools che utilizzavano (FYI la GPL richiede solo di condividere il codice se è stato modificato), quindi dovremo indovinare e provare e fare il meglio che possiamo .

Gli strumenti stessi sono script Python, questa è una nuova evoluzione da SETools 4 (in SETools 3, comandi come se sesearchfossero eseguibili binari codificati in C). Tuttavia, gli strumenti stessi mostrano ancora una versione di 3.3.8:

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

Quindi la mia ipotesi è che Google abbia preso una prima istantanea di sviluppo da SETools 4. Fino alla 4.0.0 beta SETools si basava su libsepolversoin 2.4, con la versione 4.0.0 hanno iniziato a fare affidamento sulla versione 2.5 della libreria che non è compatibile con la versione di SELinux in bundle con Android 6.0 (puoi provare a compilarlo, fallirà).

Quindi la scelta più saggia sembra andare con SETools 4.0.0 Beta.

Installa dipendenze supplementari:

sudo apt-get install python-setuptools

Scarica ed estrai il codice sorgente:

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/

A causa di un bug che interessa Flex 2.5, dobbiamo rimuovere -Wredundant-declsdai flag del compilatore:

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

E infine compilare e installare:

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

Procedura generica (o "Come sbloccarsi")

Nel caso in cui la procedura sopra non ha funzionato nel tuo caso, ecco una visione di livello superiore su come provare a progredire.

Purtroppo non c'è magia (e nessun aiuto :() da queste parti: l'unico modo per ottenere questo codice da compilare è l'approccio ciclico classico ma temuto "prova a vedere".

Prova a compilare una prima volta, molto probabilmente fallirà a causa della mancanza di alcuni *.hfile:

  1. Cerca nella external/directory di Android :

    find $ANDROID_BUILD_TOP/external -name filename.h
    

    Se trovi il file richiesto, significa che una versione specifica della libreria o dello strumento corrispondente è stata inclusa nel codice sorgente di Android. Non dovresti quindi provare a installarlo dal sistema di pacchetti di Ubuntu, ma invece compila e installa la versione inclusa nel codice sorgente di Android.

    Tieni presente che ciò va contro i consigli generali che potresti trovare sui forum: "La tua compilation fallisce a causa della mancanza di questa libreria? Installa questo pacchetto, quindi andrà bene!" , facendo ciò, molto probabilmente andrai in un problema peggiore: se una versione specifica è raggruppata, è molto probabilmente perché è necessaria una versione specifica (a causa di problemi di compatibilità o perché questa versione contiene modifiche specifiche da Google).

    A proposito, se ti stai chiedendo: ovviamente questa libreria o strumento potrebbe anche avere dipendenze che causano errori a causa della mancanza di alcuni *.hfile, e sì, dovresti applicare lo stesso approccio ciclico "prova e vedi".

  2. Cerca in tutto il sistema:

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

    Se trovi "mancante" che il file sia già presente nel tuo sistema in una posizione standard della libreria condivisa, ciò significa che probabilmente questa dipendenza è già soddisfatta nel tuo ambiente ma il Makefile che ha generato l'errore è troppo stupido per trovarlo.

    Se si chiama manualmente direttamente questo Makefile, potrebbe essere possibile impostare alcune variabili di ambiente risolvendole ( LIBDIR=/usr/lib makead esempio), altrimenti potrebbe essere necessario modificare il Makefile stesso (il pkg-configcomando potrebbe essere di aiuto prezioso per generare automaticamente i parametri di build mancanti) .

  3. Cerca nel sistema di imballaggio:

    apt-cache search filename-dev
    

    Dove filename-devrappresenta il nome del file mancante in minuscolo con l' .hestensione sostituita dal -devsuffisso (ad esempio, se Python.hnon viene trovato, cercare python-dev). Alcune modifiche nel nome esatto possono essere necessarie per trovare il pacchetto giusto.

  4. Se rimani bloccato e anche se una rapida ricerca su Internet non ha fornito alcuna risposta chiara, allora apt-filesarà il tuo migliore amico. apt-filenon è installato per impostazione predefinita, è necessario installarlo e generare il suo database:

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

    apt-fileti permette di cercare pacchetti (anche quelli disinstallati) fornendo un determinato file. Per evitare di avere troppi risultati, ti consiglio di associarlo grepcome di seguito:

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

    Se nel repository di Ubuntu è presente un pacchetto che fornisce questo file, apt-filedovrebbe essere in grado di trovarlo.

    Una volta trovato il pacchetto giusto, installalo usando apt-get install packagenamedove si packagenametrova il nome del pacchetto.

Suggerimento: Se si fregato qualcosa sul vostro sistema, il comando per reinstallare un pacchetto è questo:apt-get reinstall pkg_name. Funzionerà anche quando una classica rimozione e installazione non sarebbe possibile a causa della rottura delle dipendenze (che è molto probabile per le librerie di sistema).

Strumenti supplementari

A questo punto, ora dovresti avere un ambiente pulito che ti permetta di investigare sulle regole SELinux di Android sia in formato compilato che sorgente.

Tuttavia, la maggior parte delle probabilità è che alla fine dell'indagine desidererai agire. Nella sua forma attuale, il tuo ambiente non ti consentirà di modificare il sepolicyfile di un dispositivo . In effetti, questo file non può essere facilmente sostituito: fa parte della directory principale del dispositivo e il contenuto della directory principale viene estratto al momento dell'avvio da un file del disco RAM, che a sua volta viene archiviato nell'immagine di avvio del dispositivo.

Quindi perdi ancora due cose prima che il tuo ambiente sia completo:

  • Un modo per accedere e modificare l'immagine di avvio del dispositivo,
  • Un modo per modificare il suo sepolicyfile.

Fortunatamente, questi sono esattamente l'argomento delle ultime due sezioni di questo post! :)

Recupera e aggiorna l'immagine di avvio del dispositivo

Gli strumenti per recuperare e aggiornare l'immagine di avvio dei dispositivi possono essere utilizzati per una vasta gamma di cose oltre alla manomissione delle regole SELinux. Ho quindi creato una risposta dedicata , fare riferimento ad essa.

Modifica le regole SELinux del dispositivo

Hai due possibilità principali qui:

  • Crea un nuovo sepolicyfile dalle regole nella tua struttura di origine (cerca i .tefile per trovarli: find $ANDROID_BUILD_TOP -name \*.tesono distribuiti in più directory).
  • Modifica il sepolicyfile attualmente utilizzato dal dispositivo.

A meno che tu non abbia davvero bisogno di costruire le tue regole da zero, che è più un compito legato allo sviluppo e quindi fuori portata qui, la seconda scelta sembra di gran lunga la più sicura in quanto sei sicuro che le uniche modifiche saranno quelle tue esplicitamente fatto.

C'è stato un progetto per creare uno strumento che ti consente di decompilare un sepolicyfile in un modulo ricompilabile, che consente di modificare liberamente le regole in mezzo. Tuttavia, questo progetto è stato abbandonato in uno stato di prova. Troverai tutte le informazioni alla fine di questo post sul blog , il resto dell'articolo contiene dettagli sufficienti per consentire a chiunque sia interessato a subentrare.

Il modo attualmente raccomandato di modificare le sepolicyregole va in un'altra direzione: modificando direttamente il sepolicyfile binario. lo strumento sepolicy-inject consente proprio questo e viene attivamente mantenuto.

Per completezza, si noti che esiste un fork di questo strumento. Aggiunge alcune funzionalità, alcune delle quali sono nella lista delle cose da fare dell'autore originale (come la possibilità di rimuovere una regola), non chiedermi perché hanno scelto di fork invece di contribuire ...

Per compilare e installare sepolicy-inject, procedi semplicemente come segue:

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/

Esempio di caso d'uso

Diciamo ad esempio che si desidera aggiungere l'autorizzazione corrispondente al seguente messaggio di errore:

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

Dovrai recuperare l'immagine di avvio del dispositivo, quindi decomprimerlo per accedere al suo sepolicyfile.

Un rapido controllo usando sesearchmostra che non esiste alcuna regola di consenso (ancora!):

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

Il comando non ha output.

Quindi, utilizzare il comando seguente per aggiungere la regola richiesta (notare la somiglianza tra sesearche sepolicy-injectparametri):

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

Ora possiamo richiamare il nostro sesearchcomando:

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

sesearch l'output mostra che il criterio è stato aggiornato correttamente.

Ora puoi reimballare il boot.imgfile del dispositivo e ripristinarlo sul dispositivo. Controllare l'ora dell'ultima modifica del /sepolicyfile è un modo semplice per assicurarsi che il dispositivo stia eseguendo il sepolicyfile appena aggiornato .

Conclusione

Ora dovresti avere un ambiente completo che ti consenta di ispezionare e modificare liberamente i criteri SELinux dei dispositivi Android. Godere! :)

Come nota a margine, ci sono anche strumenti che consentono di analizzare e modificare i criteri SELinux direttamente dal dispositivo .


1
solo una nota - non fare mai "repo sync" a meno che tu non abbia un sacco di caffè da bere;) Usa invece "repo sync -q -f --force-sync -c" - ti farebbe risparmiare un sacco di tempo e spazio sul disco rigido . -q è silenzioso, -f e --force-sync ti aiuterebbe a procedere in caso di errori temporanei di rete, -c recupererebbe solo il ramo corrente. PS Uso anche i flag "-d --prune" durante lo sviluppo quando devo cancellare completamente qualsiasi modifica locale e passare alla versione manifest.
Oleksandr,

@Oleksandr: Grazie per le tue informazioni, è utile saperlo. Ho provato con la -cbandiera, ma non ho notato grandi differenze: ancora tanti dati da scaricare per il computer (25 GB), ancora più caffeina da bere;). Sono un po 'diffidente nei confronti della -fbandiera, secondo la mia comprensione questo costringerà repoa ignorare quando non è riuscito a scaricare una parte del codice sorgente e considera ancora il risultato finale come un successo. Preferisco riservare lo stato di "successo" a un recupero completo ed evitare di trovarmi in una situazione sconosciuta in cui i file potrebbero essere mancanti in modo casuale.
WhiteWinterWolf

2

Dovresti prima creare una versione precedente di libsepol dal codice AOSP (come quella corrispondente alla versione 6.0), quindi collegare sepolicy-inject, dispol, ecc. Questa ricetta ha funzionato per me su 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

a differenza del sepolicy-inject collegato al libsepol del sistema, questo funziona benissimo con / sepolicy dall'immagine 6.0 inclusa in Android SDK:

$ 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

Per gli strumenti inclusi nella distribuzione selinux, il trucco è costruirli con lo stesso DESTDIR:

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

Grazie. Questo mi ha dato una versione di sedispol che sembra funzionare, ma non riesco ancora a compilare la ricerca. Sesearch muore cercando il file include <apol/policy.h>(dall'interno di un altro policy.hfile). Sai quale modulo contiene apol?
user3188445

@ user3188445: il file apol/policy.hè fornito dal pacchetto libapol-dev(almeno è questo sui sistemi Ubuntu). Si prega di fare riferimento alla mia risposta per informazioni più dettagliate.
WhiteWinterWolf

1

Alle persone che affrontano il problema con:

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

mentre si lavora con il codice AOSP.

Supponendo che il tuo codice AOSP sia estratto in ~ / android / dir sorgente :

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

E ora sei libero di usare l' utilità di audit2allow in bundle :

./external/selinux/prebuilts/bin/audit2allow

PS Inoltre, vorrei affrontare il commento Esaminare la politica selinux di Android (v30)

Sesearch muore alla ricerca del file include (dall'interno di un altro file policy.h). Sai quale modulo contiene apol?

Costruire toolkit selinux da fonti https://github.com/SELinuxProject/selinux non è molto banale (a meno che non si stia usando Fedora). Su Ubuntu, devi installare (supponendo che tu abbia già installato strumenti di sviluppo di base come bisonte e compilatore C) libglib2.0-dev, libcap-ng-dev, xmlto, libsemanage1-dev, libustr-dev, libaudit-dev, libsepol1 -dev

Ma alla fine non sono ancora riuscito a compilarlo a causa di https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/793155 e non ho idea di come risolverlo


1
Ho anche riscontrato questo glibconfig.herrore che stai collegando alla fine del tuo post, è stato generato dal restorecondMakefile perché in esso sono stati codificati percorsi errati. Devi modificarlo per permettergli di risolvere dinamicamente i percorsi usando pkg-config. Vedi la mia risposta per maggiori dettagli.
WhiteWinterWolf


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.