Security

https://lwn.net/Articles/609254/

http://seandroid.bitbucket.org/

SELinux on Android

By Jake Edge
August 27, 2014

---

LSS 2014

One of the more surprising bits from this year's Linux Security Summit (LSS) was the progress that has been made with SELinux on Android. The project has been around for some time now and has made some impressive strides over the years. SELinux developer Stephen Smalley presented the current status of Security Enhancements for Android (SE Android) project, along with what is coming in the next Android release.

Smalley works for the US National Security Agency (NSA), but not for the signals intelligence (i.e. communication gathering) branch he was quick to point out. The job for his part of the NSA is to find ways to protect information held by the government. SELinux was originally developed by the NSA for just that purpose; extending that to work on phones is another piece of the puzzle.

At around the time of the 2013 LSS in September, the Samsung Galaxy S4 phone was shipping with SELinux and the official Android 4.3 ("Jelly Bean") included it, though both were in permissive mode, he said. That was a "baby step", but after that, 4.3 updates to the S4 and other Samsung devices put SELinux into enforcing mode, as did the Android 4.4 ("KitKat") release.

Smalley's presentation looked at the Android Trusted Computing Base (TCB) and how SELinux and other techniques are being used to protect it. All of that work has been done in public by the NSA, Google, and others—in the Android Open Source Project (AOSP) master branch. He said that he would start with what was in Android 4.4, before moving on to what is expected in the upcoming Android "L" release.

Android TCB

The Android TCB consists of the totality of the hardware and software that makes up the system. For the purposes of his talk, though, Smalley said that he would just be looking at the full Android software stack. The Linux kernel is the base of the Android TCB, but user-space code that is privileged in various ways also requires protection.

There is a loose hierarchy that runs from the kernel through the root daemons and non-root daemons (which have some capabilities) to the privileged apps that are run from/system/priv-app. It is a layering of the privileges, going from most trusted to least, he said, though the layering is "not clean". There is no easy separation between what is trusted and what isn't, nor any real attempt to determine what the applications and daemons need to be trusted to do.

Prior to adding SELinux to Android, some kernel hardening and other techniques had been applied to Android. That included setting various kernel parameters (e.g.mmap_min_addr, kptr_restrict) and using kernel features that help block privilege escalation (e.g. NOSUID, NO_NEW_PRIVS). There were also efforts to minimize the number of full-root daemons running in the system and to reduce the capability set of others. In addition, techniques to reduce the exploitability of applications like address-space layout randomization (ASLR), no-execute data sections, FORTIFY_SOURCE, and so on, were applied.

Android 4.4 was the first Google release to ship with SELinux in enforcing mode. It focused on protecting four full-root daemons (installd, netd, vold, and zygote). The intent was to protect the daemons from misuse and to contain the damage that any exploit could do. One example of the kinds of exploits that SELinux can prevent on Android is a local root vulnerability in vold from 2010—fixed in 4.4.3—that was prevented by SELinux.

Unlike standard Linux distributions, SELinux in enforcing mode is mandatory on Android 4.4 (and beyond) systems. The Android compatibility definition and tests both require SELinux. That is an advantage, Smalley said, because other parts of the system can rely on the presence of SELinux.

Another difference between Android and regular distributions is that there is no generic unconfined domain in the Android SELinux policy. Specific domains can be marked with anunconfineddomain attribute, but that is not exactly the same thing. Domains that are marked that way are not completely unrestricted by the policy, as unconfined domains are in other distributions.

Post 4.4, the strategy is to shrink the set of daemons that run with the unconfineddomain attribute. But OEMs may still add daemons with that attribute, so, in parallel, there is an effort to reduce the permissions allowed to those processes. There will also be targeted improvements to the confined domains to further reduce their ability to wreak havoc if they get compromised.

For Android 4.4, only the 4 daemons mentioned (out of a total of 47) are confined. But the Android L developer preview confines 49 out of 61 daemons and privileged apps; it also adds all third-party apps to the confined set. The current AOSP master branch, which is what Smalley expects will end up in the L release, has 62 of 65 daemons and applications confined.

Protections from the policy

Smalley then switched gears to talk about the protections that are embodied in the Android SELinux policies. In order to try to protect the kernel, there are a number of actions the policies prevent, including any process mapping low memory and reading or writing /dev/kmem and /dev/mem. Only the init process can modify process security settings (e.g.mmap_min_addr) or load SELinux policy. No domain can switch SELinux to permissive mode. All of those restrictions apply to "unconfined" domains as well.

Loadable kernel modules are supported on some Android devices, though the Nexus devices turn offCONFIG_MODULES. Only the system_server is allowed to load modules for those devices that do support it; that is done to support loading a wireless driver. In the future, some of the restrictions on module loading that Kees Cook has added may be employed on Android, Smalley said.

The user-mode helpers for hotplug have traditionally been a way to subvert the kernel by assigning an attacker-controlled helper to a particular event, then causing that event to occur. That is prevented on Android by only allowing init to configure the helpers and to only allow helpers to be executed from the root filesystem or /system.

The policies also seek to protect the integrity of files on an Android system. The/system partition has always been mounted read-only, but attacks would simply remount it read-write. The policies now lock down which processes can mount and remount. In addition, write access to/system is only allowed to the recovery process, which is only available in recovery images. Beyond that, writing to block devices, raw I/O, andmknod() are also locked down, even for objects with the unconfineddomain attribute.

Access to ptrace() has also been limited. Only the debuggerd process is allowed to ptrace other domains. Most domains have no ptrace access even within their own domain, and that includes the unconfined domains. Certain sensitive domains (e.g. init, keystore, app-to-non-app ptrace) are further protected with "neverallow" rules in the policy; those prevent any policy change from (mistakenly) overriding them.

There has been a lot of effort to ensure that there is a bare minimum that is both writable and executable. Rootfs files cannot be written, while/system can only be written from recovery—most domains can only execute files from one or the other. Except for Dalvik processes, domains cannot have executable anonymous mappings, nor change file mappings to be executable. Once again, these protections are also active for unconfined domains.

Protections against both symbolic link attacks and malicious socket IPC have been added. No domains can read symbolic links created by apps or the shell. Also, netlink sockets and sockets opened by daemons cannot be accessed by apps or the shell.

It is not just system data that is being protected, either, as there are restrictions on the/data (app data) partition as well. The original 4.4 policy allowed installd and system_server to have largely unrestricted write access to/data, but that has been tightened up considerably in the AOSP master branch. In addition, even more protections have been placed on specific security-critical data files (e.g./data/property, the system property store, and /data/misc/keystore, the certificate and key store).

There is an additional set of restrictions on the increasingly badly named "unconfined" domain. No process operations (e.g. signals) can be made to other domains and those processes cannot execute other programs without transitioning to some other domain. Those processes also have no internet access, no syslog access, and no audit access.

Protecting the policy

But what policy takes away, it can also give back, Smalley said. An OEM can "remove the goodness we baked in". Part of preventing that is the neverallow rules, but those can simply be commented out by OEMs. In order for devices to pass the compatibility test suite, however, there are two SELinux tests that must be passed. One of those ensures that the neverallow rules are still present through testing—without inspecting the policy itself.

But the project is not just applying SELinux policy. There has been a concerted effort to go beyond just creating policy to "improve the state of security on Android", he said. The need for certain capabilities has been removed from some daemons, others have been de-privileged entirely. Descriptor leaks across fork()/exec() have been found and eliminated as well. Some of those fixes have made their way back to the regular distributions to help provide better security throughout the Linux ecosystem.

SELinux has always focused on more than just the kernel, he said. It can (and does) restrict user-space programs. In 4.4, that was applied to the property service and zygote; in AOSP master that has been extended further. In addition, the hardcoded UID-based access control lists have been replaced with SELinux policy.

There have been some practical challenges in bringing SELinux to Android. Upgrades from non-SELinux devices with unlabeled filesystems required some work. Upgrading to newer policies with different labels had similar challenges. There have been other labeling issues as well, he said.

Next up are projects like simplifying the process of bringing up new devices with SELinux support, applying isolation and sandboxing features to apps, hardening the multi-user boundary in Android, and more. He encouraged anyone interested to check out thehome page and the mailing list. Smalley's slides [PDF] are also available.