I'm trying to find what policy is actually enforced by my phone using selinux. You'd think this would be easy. After all, for security it is good to verify that your policy matches expectations. Unfortunately, I've found this shockingly hard to do, because A) android seems to use a forked policy version 30, and B) the policy toolchain seems to have a very low-quality build process (lots of hard-coded paths, etc.).

Here are two things I've tried that have not worked. If I try to use off-the-shelf setools tools (such as come packaged for fedora, or can be installed from AUR with arch linux), then I get the following (after pulling /sepolicy from by phone's root directory or factory image):

$ 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, so that suggests I have to build the android version of the selinux libraries. The AOSP source tree comes with precompiled versions of some tools but these depend on old shared libraries that I don't have (like libpcre3). Anyway, it's pretty shocking if the only way to check your security policy is to trust some binary shared library you get off the net.

So here's what I did to build the android selinux libraries. On arch, I had to install ustr-selinux from AUR, because ustr uses inline where it is now required to use static inline. Okay, so far so good. Unfortunately, the build process is really gross, but I was able to get enough of it compiled and installed with the following:

git clone https://android.googlesource.com/platform/external/selinux \
export ANDROID_BUILD_TOP=$PWD/android
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"

At this point, sedispol works an an ordinary SElinux policy (like a version 29 policy.29 from fedora), but still won't show me what's going on with 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

I also tried compiling the vanilla setools3 tools against the android libraries. Again, not so easy, but I got it to work with:

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

This doesn't fully build, but builds enough of the source tree that I can execute secmds/sesearch. This sort of works on a vanilla policy.29 file (I can search -A and -T, but --all gives me operation not supported). However, it completely fails with a similar error when trying to examine an android version 30 file:

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

At this point my mind is kind of boggling that the tooling around something so critical as the system security policy is really this hard to build. Surely I must be doing something wrong. Has anyone actually managed to examine an android security policy without relying on externally distributed binary shared libraries?

I should add that I also tried the techniques suggested for rebuilding all prebuilt tools (ndk/build/tools/download-toolchain-sources.sh and ndk/build/tools/rebuild-all-prebuilt.sh). However the download-toolchain-sources.sh script is currently broken. It tries to check out old version directories that are not in the repositories any more, and anyway it doesn't appear to download any selinux related tools, despite that fact that prebuilts/python contains selinux-related code. Again, I'm shocked at how crufty these build systems are, and think there has to be an easier way. The question how can I get tools that allow me to check my android selinux policy?

5 Answers 5


First of all, I must admit that I fully agree with your "I've found this shockingly hard to do" statement. Google has designed Android mainly from a consumer perspective, and not for power users. The result is that, as soon as you want to do something outside of using the latest Facebook app or playing with Candy Crush, you very quickly find yourself back in realm of early-2000 Linux, when a developer-like knowledge was required to change what should be simple settings. I believe that the situation will fastly evolve as Android system gets more mature, but for now we have to do with what we have got...

As you said, there are two reasons why it is necessary to compile your own SELinux toolset:

  • The system provided toolset is usually a version behind. While Android's SELinux relies on policy DB version 30, current Linux boxes usually handle only version up to 29.
  • Even if it would be more recent it would not help, in fact building SELinux from upstream code (which is easilly done, at least on Fedora machines following upstream recommendations) effectively allows the system to handle policy DB version 30, however Android's SELinux has been heavilly modified (Google documentation highlights a few modifications) so trying to handle Android's SELinux fails due to syntax and parsing errors.

So, to keep on the Android's SELinux analysis quest, we will have to put our hands in the dirt... in the cleanest possible way:

  • First we will setup a sane environment,
  • Once this is done we will compile Android's SELinux libraries and first tools,
  • On top of them we will build SELinux tools,
  • We will finish by adding a few supplementary utilities.

Setup a proper environment

Environment properties

The cleanest recommended, an possibly maybe only reliably working way is to dedicate a environment to your Android work:

  • A virtual machine is perfectly fine (if not the best option). Prefer to use a VMware one since you will have to connect your phone through USB to the guest system. The free alternative Qemu doesn't seem to handle such task very well. I did not try with other virualization software.

  • It will need to be a 64 bits system, otherwise the code will simply not compile due to integers being of the wrong size.

  • It is strongly recommended, possibly mandatory, to use a Ubuntu system. Feel free to use Xubuntu instead if you prefer XFCE's lighter desktop environment, this does not change the system's core and available package and will have no impact on your Android related work (whatever I say about Ubuntu in this procedure also applies to Xubuntu). You may find in Android's SELinux source tree some ReadMe files recommending the use of Fedora instead, these files are inherited from upstream NSA's SELinux project and their content do not necessarily match Google's Android.

  • The exact version of Unbuntu to use depends on the version of Android you want to build. For Android 6.0, Ubuntu 14.04 (Trusty) is recommended. Check Google requirements page for more information.

  • You will need plenty of disk space (at least 50GB if you plan only SELinux-related investigation, at least 100GB if you plan for a complete build of Android). CPU and memory are less relevant, they only impact time for a full build and will have no real impact for SELinux related tasks.

Using Ubuntu has two main advantages:

  • By using the recommended system, you are working in a well-known and well-tested environment: system libraries, tools and packages are at the version and location expected by the project.

  • And more specifically in our current case: Ubuntu itself relies on AppArmor which is a SELinux alternative, it does not use SELinux. The good news is that you will therefore be able to install Android's SELinux tools and binaries system-wide without risking to alter system reliability.

Environment installation procedure

You can install Ubuntu the traditional way by starting from a full-fledged live-DVD, but a faster alternative is to use a netboot install (textmode install) and select the desktop environment you prefer at the end. Doing so will save you the initial update time by directly installing up-to-date packages version instead of first installing obsolete ones, then asking to apply 389 pending updates on the first boot.

The ISO for Ubuntu/Xubuntu 14.04 (same ISO) netboot installer is available here.

To skip VMware's troublesome "Easy Install" feature, it's a good habit to start by selecting the "I will install the operating system later" option.

Be sure to select Linux, then Ubuntu 64 bits as guest OS.

The VM will need the following ressources:

  • Mandatory: disk space must be at the very least 40GB (the default 20 GB will not be enough, the source code alone takes more space than that), higher is recommended. A full build requires a 100 GB disk minimum, this is the value I usually take. Do not forget that this setting is just a maximum limit: the actual size taken by the VM grows dynamically with guest's requests.
  • Facultative: Increase RAM from 1024 to at least 2048 or higher (depends on your host capacity, I use 4096),
  • Facultative: Increase the number of processor cores from 1 to 2 or higher (depends on your host capacity, I use 3).
  • The CD-Rom must point to the installation ISO file.
  • You may want to switch USB from the default 1.1 to 2.0 as the former may give warnings when you connect your device. Depending on your usage, you can also safely uncheck "Automatically connect new USB devices" and "Share Bluetooth devices with the virtual machine".
  • Depending on your environment, you may also need to tweak display settings (disable 3D, enforce a screen size).


  • If you choosed the netboot install, do not forget to select your desktop environment (Ubuntu desktop or Xubuntu desktop) when reaching the Software selection screen, or you will end-up with a minimal text-only environment!
  • Upon first boot, refuse to upgrade to the latest release: the whole point here is to stay in 14.04!

Upon first boot, one of the first you may want to do is install Linux guest tools:

sudo apt-get install open-vm-tools

This packet put boot-time triggers, its installation will therefore be complete only after a guest restart.

Fetch Android source code

While similar, the procedure details depends on the chosen ROM:

  • For CyanogenMod, search for your device (select the vendor first) then click on the "How to build CyanogenMod" link to get instruction adapted for your device.
  • For AOSP, follow the procedure which starts here.

It can be worth noting that CyanogeMod bundles in its source tree a tool allowing you to unpack boot.img files. To say it differently, CyanogenMod provides you a tool which will allow you to access the sepolicy file stored in devices and ROM archives. Google's AOSP does not provide such tool, so if you have no other imperative using CyanogenMod's source tree may be the most convenient choice, otherwise you will have to install it appart (which is quick and easy to do, so no worry here).

Here I'm following CyanogenMod 13.0 (Android 6.0) procedure. Explanation on the commands used is available on the pages linked above. Please read them, the typescript below is given only for reference purposes.

Tip: While I use apt-get in this post to stick to the lowest common denominator and keep everybody happy, you may prefer to use aptitude instead since it will take care of the dependencies in a better way (when removing a package which required the installation of some dependencies, these dependencies will be removed too, leaving your system cleaner). AFAIK the aptitude command must be installed in Ubuntu but is available by default on 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
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

Now you have a clean and nearly complete source tree. The proprietary blobs are missing, but you don't need them for SELinux related tasks.

Tip: Fetching the sources is a tedious process, it may be worth to do a snapshot or backup of your VM now.

Compile and install Android's SELinux toolset and libraries

Now the funny part of the trip begins ;) !

Until now the procedure should have been pretty straightforward. The goal was mainly to ensure that you have the very same environment as me. If you do, the sequel should remain straightforward too.

Under the hood Google's do not hesitate to apply deep changes to Android's source code between versions, therefore the exact compilation steps will be quite certainly version dependent (for instance AOSP master shows that the sepolicy/ directory will be moved).

I will first share my exact procedure to compile and install Android's SElinux libraries and toolset, but in order to keep the relevance of this post over time I will then add some notes about the generic approach to follow in order to solve most compilation issues.

Step-by-step procedure

Android's SELinux libraries provide the abstraction layer which will allow upper layer software to deal with Android-specific SELinux policy files. We will therefore need to compule and install them first (which, in itself, actually represents the core if the difficulties here, until you've found your way).

We will then be able to build and install SELinux tools. As we will see, fortunately these do not need to be Android specific, they only need to match the SELinux library version.

This procedure has been tested both using CyanogenMod and AOSP source code trees.

Compile and install Android SELinux libraries and first tools

First install dependances:

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

In this post the variable $ANDROID_BUILD_TOP stores your source location (the directory where you issued the repo sync command). Feel free to change its name as you like.

source ./build/envsetup.sh

By default the policy core utils compilation fails due to restorecond's Makefile being unable to locate some libraries. You have to edit this Makefile in order to use paths dynamically generated by pkg-config instead of hardcoded ones (do not confuse backticks with single quotes!):

sed -i 's/^CFLAGS ?= -g -Werror -Wall -W$/& `pkg-config --cflags --libs dbus-1 gtk+-2.0`/' \

Feel free to open the Makefile with some text editor to ensure that the modification has been correctly taken into account.

And now compile and install:

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/
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
sudo make install
make swigify
sudo make install-pywrap
sudo cp ./checkpolicy/test/{dispol,dismod} /usr/bin/

Attention: Do not miss the EMFLAGS=-fPIC environment variable setting when building libselinux. It will not generate any error yet, but in the next step you will be unable to build SETools. In case you missed it or did anything else wrong, simply issue a make clean and restart your compilation.

Compile and install SELinux tools

SELinux tools are provided in a prebuilt form which includes:

  • Python scripts (and their shell script wrappers) within the $ANDROID_BUILD_TOP/external/selinux/prebuilts/bin/ directory
  • Python packages (including *.o compiled files) below $ANDROID_BUILD_TOP/prebuilts/python/linux-x86/2.7.5/lib/python2.7/site-packages/.

I would have expected the source code of these tools to be available below $ANDROID_BUILD_TOP/external, but it isn't. Actually, I did not find any place where Google shared the exact version of SETools they used (FYI the GPL only mandates to share the code if it has been modified), so we will have to guess and try and do as best as we can.

The tools themselves are Python scripts, this a new evolution from SETools 4 (in SETools 3, commands like sesearch were binary executable coded in C). However, the tools themselves still show a version of 3.3.8:

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

So my guess is that Google took some early development snapshot from SETools 4. Until 4.0.0 beta SETools relied on libsepol versoin 2.4, with 4.0.0 release they started to rely on the version 2.5 of the library which is not compatible with the version of SELinux bundled in Android 6.0 (you can try to compile this, it will just fail).

So the wisest choice seems to go with SETools 4.0.0 Beta.

Install supplementary dependencies:

sudo apt-get install python-setuptools

Download and extract the source code:

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/

Due to a bug affecting Flex 2.5, we need to remove -Wredundant-decls from compiler's flags:

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

And finally compile and install:

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

Generic procedure (or "How to unstuck yourself")

In case the procedure above did not work in your case, here is a higher level view on how to try to progress.

There is sadly no magic (and no helper :( ) around here: the only way to get this code to compile is the classical yet dreaded cyclic "try-and-see" approach.

Try to compile a first time, it will most likely fail due to some *.h file being not found:

  1. Search in Android's external/ directory:

    find $ANDROID_BUILD_TOP/external -name filename.h

    If you find the requested file, then this means that a specific version of the corresponding library or tool has been bundled within Android source code. You should therefore not try to install it from Ubuntu's package system, but instead compile and install the version bundled in Android source code.

    Be aware that this goes against general advice you may found on forums: "Your compilation fails because of this library missing? Install this package then it will be fine!", by doing this you will most probably just go into worse issue: if a specific version is bundled, it is most probably because a specific version is needed (due to compatibility issues or because this version contains specific changes from Google).

    BTW, if you are wondering: of course this library or tool may also have dependencies raising errors due to some *.h file being not found, and yes you should apply this very same cyclic "try-and-see" approach.

  2. Search systemwide:

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

    If you find "missing" the file to be already present in your system in some standard shared library location, this mean that this dependency is probably already met in your environment but the Makefile who raised the error is too dumb to find it.

    If you manually directly call this Makefile, it may be possible for you to set some environment variable fixing this (LIBDIR=/usr/lib make for instance), otherwise you may need to modify the Makefile itself (the pkg-config command may be of precious help to automatically generate missing build parameters).

  3. Search in the packaging system:

    apt-cache search filename-dev

    Where filename-dev represents the name of the missing file in lowercase with the .h extension replaced by the -dev suffix (for instance, if Python.h is not found, search for python-dev). Some tweaking in the exact name may be needed to find the right package.

  4. If you remain stuck and that even a quick search on Internet did not provide any clear answer, then apt-file will be your best friend. apt-file is not installed by default, you need to install it and generate its database:

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

    apt-file allows you to search for packages (even uninstalled ones) providing a particular file. To avoid having too much result, I recommend to associate it with grep as below:

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

    If there is a package in Ubuntu's repository providing this file, then apt-file should be able to find it.

    Once you've found the right package, install it using apt-get install packagename where packagename is your package's name.

Tip: If you screwed something on your system, the command to reinstall a package is this one: apt-get reinstall pkg_name. It will work even when a classical remove & install would not be possible due to breaking dependencies (which is most likely for system's libraries).

Supplementary tools

At this step, you should now have a clean environment allowing you to investigate Android's SELinux rules both in compiled and source formats.

However, most chances are that at the end of your investigation you will want to take some action. In its current shape, your environment will not permit you to modify a device's sepolicy file. In fact, this file cannot be easilly replaced: it is part of the device root directory, and the content of the root directory is extracter at boot time from a RAM disk file, which in turn is stored in the device's boot image.

So you still miss two things before your environment is complete:

  • A way to access and modify the device's boot image,
  • A way to modify its sepolicy file.

Fortunately, these are precisely the subject of the two last sections of this post! :)

Fetch and update device's boot image

Tools to fetch and update devices' boot image can be used for a wide variety of things apart from SELinux rules tampering. I have therefore created a dedicated answer, please refer to it.

Modify device's SELinux rules

You have two main possibilities here:

  • Build a new sepolicy file from the rules in your source tree (search for .te files to find them: find $ANDROID_BUILD_TOP -name \*.te, they are spread into several directories).
  • Modify the sepolicy file currently used by the device.

Unless you really need to build your rules from scratch, which is more a development-related task and therefore out-of-scope here, the second choice seems by far the safest one as you are sure that the only changes will be the one your explicitely made.

There has been a project to make a tool allowing you to decompile a sepolicy file into a recompilable form, allowing to freely edit rules in between. However this project has been abandonned in proof-of-concept state. You will find all information at the end of this blog post, the rest of the article contains enough details to allow anyone else interested to take over.

The currently recommended way to alter sepolicy rules goes another route: by directly modifying the sepolicy binary file. sepolicy-inject tool allows just that and is actively maintained.

For completeness sake, note that a fork of this tool exist. It adds a few features, some of them being on the original author's to-do list (like the possibility to remove a rule), don't ask me why they choosed to fork instead of contributing...

To compile and install sepolicy-inject, simply proceed as follow:

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/

Use-case example

Let's say for instance you want to add the autorization matching the following error message:

avc: denied { read } for pid=128 comm="file-storage"
dev="mmcblk0p28" ino=811035 scontext=u:r:kernel:s0
tcontext=u:object_r:media_rw_data_file:s0 tclass=file permissive=0

You will need to fetch device's boot image, then unpack it to get access to it's sepolicy file.

A quick check using sesearch shows that there is indeed no allow rule (yet!):

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

The command has no output.

Then, use the command below to add the required rule (note the similarity between sesearch and sepolicy-inject parameters):

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

Now we can call back our sesearch command:

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

sesearch output shows that the policy has correctly been updated.

You can now repack the device's boot.img file and flash it back to the device. Checking the last modification time of the /sepolicy file is an easy way to ensure that your device is now running the newly updated sepolicy file.


You should now have a complete environment allowing you to freely inspect and modify Android devices SELinux policies. Enjoy! :)

As a side note, there are also tools allowing to analyze and modify SELinux policy directly from the device.

  • 1
    just one note - never do "repo sync" unless you have a plenty of coffee to drink ;) Use "repo sync -q -f --force-sync -c" instead - it would save you tons of time and hard drive space. -q is quiet, -f and --force-sync would help you to proceed in case of temporary network errors, -c would fetch current branch only. P.S. I also use "-d --prune" flags during development when I need to fully erase any local changes and switch to manifest version.
    – Oleksandr
    Aug 16, 2016 at 12:34
  • @Oleksandr: Thanks for your information, this is useful to know. I tested with the -c flag, but did not notice any big difference: still as much data for the computer to download (25 GB), still as much caffeine for me to drink ;). I'm a bit wary of the -f flag, as per my understanding this will force repo to ignore when it failed to download some part of the source code and still consider the final result as a success. I prefer to reserve the "success" state to a complete fetch, and avoid finding myself in an unknown situation where files may be randomly missing. Aug 16, 2016 at 19:39

You should first build an older version of libsepol from the AOSP code (like the one corresponding the 6.0 version), then link sepolicy-inject, dispol, etc against it. This recipe worked for me on 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
cd /to/the/selinux-inject-source-dir
make LIBDIR=$libsepol

unlike the sepolicy-inject linked against the system's libsepol, this one works fine with the /sepolicy from the 6.0 image included in the 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

For the tools included in the selinux distribution, the trick is to build them with the same DESTDIR:

cd libsepol
make DESTDIR=/some/dir install
cd ../checkpolicy
make DESTDIR=/some/dir
# here you have a working 'dispol' in the 'test' subdir
  • Thanks. This gave me a version of sedispol that seems to work, but I still can't compile sesearch. Sesearch dies looking for the include file <apol/policy.h> (from within another policy.h file). Do you know which module contains apol? Feb 24, 2016 at 8:38
  • @user3188445: The file apol/policy.h is provided by the package libapol-dev (at least it is this one on Ubuntu systems). Please refer to my answer for more detailed information. Aug 15, 2016 at 14:07

To the people facing the issue with:

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

while working with AOSP code.

Assuming, your AOSP code is checked out to ~/android/source dir:

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

And now you are free to use bundled audit2allow utility:


P.S. Also, I would like to address comment Examine android (v30) selinux policy

Sesearch dies looking for the include file (from within another policy.h file). Do you know which module contains apol?

Building selinux toolkit from sources https://github.com/SELinuxProject/selinux is not very trivial (unless you are using Fedora). On Ubuntu, you need to install (assuming you've already installed basic dev tools like bison and C compiler) libglib2.0-dev, libcap-ng-dev, xmlto, libsemanage1-dev, libustr-dev, libaudit-dev, libsepol1-dev

But at the end I've still failed to compile it because of https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/793155 and have no idea how to resolve it

  • 1
    I also encountered this glibconfig.h error you are linking at the end of your post, it was raised by restorecond's Makefile because wrong paths were hard-coded in it. You have to modify it to let it dynamically resolve paths using pkg-config. See my answer for more details. Aug 15, 2016 at 14:10

You should try to apply this patch to the sources of libsepol, and then incrementaly rebuild all that stuff. It worked for me in the sam issue

You can try to use libsepol clone with applied patch from this repo https://[email protected]/metizik/selinux_tools.git I use it to build dispol under Windows, and it works to me fine (still notice that I'm using cygwin for this)


audit2allow, audit2why, and sesearch are all broken with the update AOSP upstream policy to v.30.

You have to apply patches below and rebuild your Android tree to update policy db. These patched already merged to master branch and available starting from Android N.

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .