What is SE for Android?

Security Enhancements for Android (SE for Android) is a project to identify and address critical gaps in the security of Android. Initially, the project is enabling the use of SELinux in Android in order to limit the damage that can be done by flawed or malicious apps and in order to enforce separation guarantees between apps. However, the scope of the project is not limited to SELinux.

SE for Android also refers to the reference implementation produced by the project. The current reference implementation provides a worked example of how to enable and apply SELinux at the lower layers of the Android software stack and provides a working demonstration of the value provided by SELinux in confining various root exploits and application vulnerabilities.

注：In the software development process, a reference implementation (or, less frequently, sample implementation or model implementation) is the standard from which all other implementations and corresponding customizations are derived. An improvement to a reference implementation reflects an unchanging specification.

Merge Status

The Android SELinux code and policy developed by the SE for Android project has been merged to mainline Android as of the Android 5.0 (Lollipop) release, although further work continues in the Android Open Source Project (AOSP) master branch. Android 4.3 was the first Android release version to enable the original SELinux support contributed by the SE for Android project. Android 4.4 put SELinux into enforcing mode for the first time, beginning by confining a specific set of root daemons. Android 5.0 (and later) extends SELinux protection to all services and apps on Android. Android 6.0 further applies SELinux to enforcing specific security goals.

The Android SELinux support is discussed in https://source.android.com/devices/tech/security/selinux/index.html.

As a result of the merging of these security enhancements into mainline Android, the SE for Android project is no longer maintaining its own separate repositories and branches. If you wish to leverage or further build upon these security enhancements, you should directly work from the appropriate AOSP branches.

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.

getenforce
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.

Policy

The SE for Android policy sources are located under external/sepolicy. The policy consists of source files used to generate the SELinux kernel policy file, a file_contexts configuration, a property_contexts configuration, a seapp_contexts configuration, and a mac_permissions.xml configuration. The file_contexts configuration is used to label files at build time (e.g. the system partition) and at runtime (e.g. device nodes, service socket files, /data directories created by init.rc, …). The property_contexts configuration is used to specify the security context of Android properties for permission checking purposes. The seapp_contexts configuration is used to label app processes and app package directories. The mac_permissions.xml configuration is the middleware MAC policy. The property_contexts, seapp_contexts, and mac_permissions.xml configurations are unique to SE for Android (i.e. they were not part of the regular SELinux policy).

Device-specific policy can be specified by defining BOARD_SEPOLICY* variables in a BoardConfig.mk file under the device/vendor/device or vendor/vendor/device directories. An example can be found in device/lge/hammerhead/BoardConfig.mk, which defines these variables to reference device-specific policy files under device/lge/hammerhead/sepolicy. Documentation for per-device policy can be found in external/sepolicy/README.

SELinux kernel policy is presently compiled as part of the Android build and added to the ramdisk image so that it can be loaded by init very early in boot, before mounting the system partition. Once the data partition has been mounted, policy can be updated by placing policy files under /data/security/current, and setting the selinux.reload_policy property to 1 (setprop selinux.reload_policy 1). The init.rc file sets this property from post-fs-data to reload policy from /data/security if present. Policy updates are only loaded if the /data/security/current/selinux_version file matches the /selinux_version file; this prevents loading an older policy update after an OTA. All of the policy files (i.e. selinux_version, sepolicy, *_contexts, mac_permissions.xml) must be present under /data/security/current in order for a policy update to work correctly.

Addressing Hidden Denials

If you encounter permission denials while in enforcing mode but do not see any avc: denied messages in the dmesg or logcat output, then you may need to install a modified policy with dontaudit rules stripped in order to find the underlying cause. The dontaudit rules are normally present to avoid noise in the audit logs from harmless application probing or permission tests used to select a different code path rather than being required for operation. To install and load the policy with dontaudit rules removed, do the following:

cd out/target/product/device/obj/ETC/sepolicy_intermediates
adb push sepolicy.dontaudit /data/local/tmp
adb shell
su
load_policy /data/local/tmp/sepolicy.dontaudit

Then re-test the operation that was failing and collect the avc: denied messages from dmesg. Be careful to not blindly allow all such permissions as many of them will be unnecessary and not directly relevant to the operation that was failing. When you are finished testing, revert to the original policy as follows:

adb shell
su
load_policy /sepolicy

Running the CTS

If you want to run the Android Compatibility Test Suite (CTS) with SE for Android, you should follow the standard instructions as per http://source.android.com/compatibility/.

You may wish to collect any permission denials and log messages that occur during the CTS execution for later use in diagnosing failures and amending the policy to better support the CTS. However, note that many denials occur normally during the CTS and should not necessarily be allowed. In particular, various security-related tests may intentionally trigger denials and other tests will often trigger harmless denials from filesystem or /proc/pid traversals that are not required for correct operation. Do not amend the policy unless a denial causes a test failure, and even then, it is best to bring the issue to the seandroid-list mailing list for discussion on the best solution. You can collect denial messages from the kernel ring buffer and from logcat as follows:

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

Individual CTS tests that test SELinux settings can be run as follows:

cts-tradefed
run cts -c android.security.cts.KernelSettingsTest
run cts -c android.security.cts.SELinuxTest
run cts -c android.security.cts.SELinuxDomainTest
run cts -c android.cts.security.SELinuxHostTest
run cts -c android.cts.security.SELinuxNeverallowRulesTest

In AOSP master, SELinuxDomainTest has been migrated into SELinuxHostTest.

External Tools

fixup : script for converting allow rules to use macros

sepolicy-inject : tool for adding rules to an existing binary policy

Security Enhancements for Android