I haven't been the best about updating my tools or blog in the past 12 months, I know. Behind the scenes, however, I've continued to perform embedded device research (not just Android!), and still try to maintain a toolset that works. In 2018, I spoke at ANYCON on my continued research on SEAndroid. For those unfamiliar, this has been a focus of mine since 2016 when I realized how much of an impact SEAndroid was having on the threat landscape of Android devices. In 2017, I started creating tools to process and navigate the SEAndroid details from a given device (part of my dtf project, which hasn't gotten much love lately). I realized fairly quickly that the process of analyzing the SEAndroid policy on a given device unexpectedly tricky. In fact, I still have to reference the extremely verbose answer provided by StackOverflow user WhiteWinterWolf when answering the question: How can I parse v30 SELinux policies for Android?
Why does that matter today? Because it's still not easy.
"setools" as a project provides a number of utilities that operate on the binary SELinux policy file. These utilities (implemented as a Python module with SWIG bindings) allow you to diff policies ("sediff"), extract metadata ("seinfo"), and run queries to answer questions about the policy ("sesearch"). "sesearch" is extremely useful for determining powerful contexts, locating mis-configurations, and a general understanding of the given policy. I think it's sufficient to say that these tools are required if your goal is to understand a device's SELinux policy or stage a more serious attack.
I recently needed to rebuild my Android device testing environment and realized - I'm going to need to follow WhiteWinterWolfs tutorial on how to build the tools again. To summarize his lengthy response, you need to:
Why does that matter today? Because it's still not easy.
Parsing SEAndroid, How Hard Can It Be?
It's not easy because Google has decided to fork the SELinux project and alter the project to suit the needs of the Android operating system. There's nothing inherently wrong with this and the features added by Google make a lot of sense. The problem is that they don't expect anyone else to build the tools to interact with their fork of SELinux (called "setools"). This is unfortunate, because this is exactly what I want to do when analyzing the policy from a new device that I did not develop."setools" as a project provides a number of utilities that operate on the binary SELinux policy file. These utilities (implemented as a Python module with SWIG bindings) allow you to diff policies ("sediff"), extract metadata ("seinfo"), and run queries to answer questions about the policy ("sesearch"). "sesearch" is extremely useful for determining powerful contexts, locating mis-configurations, and a general understanding of the given policy. I think it's sufficient to say that these tools are required if your goal is to understand a device's SELinux policy or stage a more serious attack.
I recently needed to rebuild my Android device testing environment and realized - I'm going to need to follow WhiteWinterWolfs tutorial on how to build the tools again. To summarize his lengthy response, you need to:
- Create and configure a Ubuntu VM where you will build Android. The current approved version of Ubuntu for building is Ubuntu 4.04 LTS, which is not suitable for actual testing.
- Clone the Android Open Source Project ("AOSP") for a version of Android. This can ultimately consume 30-60 GB of storage space post-build and takes hours to clone. Also, WhiteWinterWolfs answer references the now defunct Cyanogenmod and Android 6.0 branches. This is also not ideal for modern devices, as Android made some breaking changes in 7.0.
- Build portions of Android, then specifically build and install the SELinux components. This is not something most users will end up doing, which results in 2 problems:
- This is something usually Google would do, so you're going to have to probably patch and troubleshoot as you slowly build the tools. For 7.0 or newer, you actually will need to patch/modify broken files, since they do not compile normally.
- This installs the newly-ported SELinux libraries locally. Remember that I mentioned Google recommends building with 14.04? This means you either need to use 14.04 as a base (bad idea), or somehow move them to a newer distribution. Also not a great idea.
- Download and compile an old "beta" version of "setools" 4.0.0, which will link against the currently installed SELinux binaries (which you built in Step 3). This version is now 2+ years old, and will not work for devices 7.0 forward.
After hours of troubleshooting, building, and banging your head against a wall, you can finally start answering questions about the SEAndroid policy of your test device offline, but it's not a great workflow. I wanted something better, which is the reason for this post.
The Solution: android-setools
Since I recently went through the process of recreating the environment to generate the tools I needed (which includes "sesearch", "seinfo", and "sediff"), I decided to take a more long-term approach. This time around, I took note of what each step in WhiteWinterWolf's tutorial was actually doing, and brainstormed a way to make the process more streamlined. The result was a Debian package ("DEB") along with a Makefile that streamlines the process, and drops the lengthy dependencies needed. The project is called "android-setools", and it's currently on my Github.
With "android-setools", you no longer need to build an Android building environment, clone the AOSP tree, or patch random files until things compile correctly. You can simply install a few building dependencies, clone my repo, and use the Makefile to get started. The build is also tested through Ubuntu 18.04, so you can do it from your main test environment. Finally, since I needed both pre-7.0 and 7.0+ to work, I included make tasks for both of these situations. You unfortunately cannot use both at the same time (suggestions welcome), but at least rebuilding is easy and painless. Once built, you can use "sesearch", "sediff", seinfo", and others just like you normally would for standard SELinux policies.
I've provided instructions to use the tool in the README.md file for the project. While the solution is not perfect, it will definitely reduce the time needed to prep an environment to probably 5 minutes. Questions, feedback, or bug fixes are of course welcome on the Github's issue tracker. I hope this utility will be helpful for people and good luck navigating through SEAndroid!