SELinux guides

android_selinux.md

About

SELinux is a security enhancement to Linux which allows users and administrators more control over access control.

Access can be constrained on such variables as which users and applications can access which resources. These resources may take the form of files. Standard Linux access controls, such as file modes (-rwxr-xr-x) are modifiable by the user and the applications which the user runs. Conversely, SELinux access controls are determined by a policy loaded on the system which may not be changed by careless users or misbehaving applications.

SELinux also adds finer granularity to access controls. Instead of only being able to specify who can read, write or execute a file, for example, SELinux lets you specify who can unlink, append only, move a file and so on. SELinux allows you to specify access to many resources other than files as well, such as network resources and interprocess communication (IPC).

Deeper understanding

So you think its easy writing a selinux policy? It actually is - I mean .. technically.

There are tools which auto generate policies from a log but are they good to use? It depends. and here it stops being easy as you, the integrator have to have a deep understanding what the IMPACT of each policy has.

To be able to go on you should really go through this first:

• SELinux FAQ
• https://www.billauer.co.il/selinux-policy-module-howto.html
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/using_selinux/index
• and really make use of your favorite search engine!

as it helps a lot to understand how it works. and why is that important? because only if you know how it works you can make a decision if an auto generated policy is doing any harm or not.

How to write a policy (extremely ROUGH)?

On Ubuntu you can install audit2allow like this: apt install policycoreutils-python-utils

the process usally is:

1. fetching the denials:
   • using Linux: adb logcat -b all |grep avc: > /tmp/denies
   • using Windows: adb shell "logcat -b all |grep avc: > /sdcard/Download/denies" + adb pull /sdcard/Download/denies
2. creating the current policy in your android sources dir
   • source build/envsetup.sh + lunch <device> as usual
   • mka libselinux sepolicy
3. autogen policies: cat /tmp/denies |audit2allow -p out/target/product/<device-codename>/root/sepolicy
4. check the output + add the policies to their according filename (ensure you don't open security holes)
5. start to build the sepolicies (mka sepolicy)
6. fix neverallows, etc occurring during the build
7. if all is fixed build the full OS as usual

Step 6 in particular will have you tearing your hair out.. and that's why it is so important to understand the whole thing or learn by doing - keep in mind, however, that workarounds or too wide policies open holes that negate the security benefits of SELinux.

advanced debug

In order to debug you will require root permissions. Either you do an eng build or userdebug (enable adb root in developer options) or last but not least using a root tool like Magisk.

1. For debugging and testing live without building hundreds times you should download the se-tools or use magiskpolicy / aka supolicy
2. put the ones matching your device architecture to your device, e.g.

adb push setools-arm64-v8a/se* /sdcard/Download/
adb shell
(then "su" when using magisk)
mount -oremount,rw / (or "/vendor")
cp /sdcard/Download/se* /vendor/bin/
chmod +x /vendor/bin/se*

3. now you can make use of:
   • seinfo to see the current active policy stats (and more --help)
   • sesearch (e.g. sesearch --allow -s cameraserver) to see the current active rules
   • sepolicy-inject to inject policies on-the-fly!

Also a good-to-know hint: you can grab any existing policy from the device and generate a readable conf like this:

adb pull /sys/fs/selinux/policy sepolicy
checkpolicy -M -F -b -o policy.conf sepolicy

or if you build and did "mka sepolicy" before/after your build you can do that:
checkpolicy -M -F -b -o policy.conf out/target/product/<device>/root/sepolicy

Last but not least:

!!! You do NOT need to solve ALL denials you find !!!

Denials in your log are not necessarily something you should fix, really. The rule of thumb is that you fix denials ONLY when they fix a problem - and if you are sure (enough) it is worth to write an allow (i.e. no breaking the security).