Contents Previous Next

Getting Started

Once you have the emulator or a device running SE for Android, you can run adb shell and then look for signs that SELinux is present, e.g.

ls -Z
ps -Z
dmesg | grep SELinux

On 4.4 and later, SELinux defaults to enforcing unless androidboot.selinux=permissive is passed as a command line argument to the kernel.

Before putting a new board/device into enforcing mode, make sure you don't have any residual denials to address in your policy, e.g.

adb shell su 0 dmesg | grep avc
should show no output.

In 5.0 and later, avc denials are now also logged to logcat, so you can alternatively check for denials in your logcat output, e.g.

adb logcat | grep avc:

To change enforcing mode at runtime, you can run the setenforce command from an adb root shell, e.g.:

# Check current enforcing status.
adb shell getenforce
# Switch to enforcing.
adb shell su 0 setenforce 1
# Switch back to permissive.
adb shell su 0 setenforce 0

In addition to the global enforcing mode, SELinux supports a per-domain permissive mode that allows specific processes to operate in permissive mode while the rest of the system remains enforcing. In 5.0, per-domain permissive mode is specified in the policy sources via "permissive_or_unconfined()" macro calls; these calls will make the domain permissive in -userdebug or -eng builds but make it enforcing but mostly unconfined in -user builds. In master, the unconfined domain has been removed but you can still make a domain permissive for development via "userdebug_or_eng(`permissive name-of-domain;')" calls; these calls will make the domain permissive in -userdebug or -eng builds but fully enforcing and confined in -user builds.

You can capture policy denials for later use in policy debugging as follows:

adb shell su 0 cat /proc/kmsg > dmesg.txt &

On 5.0 and later, the policy denials are now also available in logcat once logd starts running, so you can capture them as follows:

adb logcat > logcat.txt &

You can later apply standard SELinux tools such as audit2allow to these logs, as in:

audit2allow -p out/target/product/device/root/sepolicy < dmesg.txt

However, note that you must specify that you are using a policy other than the SELinux policy active on the build host by using the -p option as shown above.

You can get augmented audit information, including syscall information, full pathnames, etc, by using our modified kernels that enable syscall audit and pathname collection by default.

Contents Previous Next