What is…Security Enhanced (SE) Android?
When writing up the Samsung KNOX release recently – it’s a means of managing secure data access, in a corporate environment – the company stated it was built upon Security Enhanced (SE) Android. What is that, I wondered? Time for another in our What is…? series, looking at aspects of Android technology that are somewhat beneath the radar.
Security, security, security
SE Android originated with the (US) National Security Agency, an intelligence agency responsible for protecting US government communications systems. It sought to address the increasing use of mobile devices throughout government bodies, along with a perceived need for improved security. Android was chosen, for its widespread use and the openness or adaptability of the platform.
Basically, the goal is to stop mobile apps granting themselves extra privileges, or prevent apps from sharing too much data, or prevent the bypass of security features. Generally, help protect the integrity of apps and data…
But the NSA has emphasised that SE Android is NOT:
- A government-specific Android
- A fork of Android
- A complete solution for all security concerns
- A product
- Specially evaluated or approved for use
What is involved in SE Android? Well, as the sections below cover, it requires the enhancement of standard Linux, the use of policy files to specify levels of access, a variety of specific features, and its own distribution…
Building on Linux
First things first, Security Enhanced (SE) Android is actually built on SELinux (which is applied at the lower layers of the Android software stack).
What is SELinux? It is a security enhancement to the Linux kernel that gives admins, and users, more features for access control, for example what resources can be accessed by particular applications or users.
Standard Linux access controls are potentially modifiable by a user and the applications they run. For example, chmod shell commands are for enabling or disabling read/write/execute permissions. SELinux controls, however, are pre-determined by a policy loaded on the system. They can not be changed, either by careless or malicious users or misbehaving applications.
According to the SELinux wiki (the official Security Enhanced Linux (SELinux) project pages):
“SE Android 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 reloaded from /data/security by placing policy files under /data/security and setting the selinux.reload_policy property to 1 (setprop selinux.reload_policy 1). This will trigger a reload of policy by init, which will also restart ueventd and installd so that they can reload the policy configuration files relevant to their operation.”
Also, SELinux provides a finer granularity of control – you can specify who can unlink, append, or move files, for example.
Finally, you can specify access to resources other than files, for example network resources and even interprocess communication.
There is a FAQ for SELinux and you can read more on the project’s official page for SE Android, which provides links to SE Android presentations, details of how to get the SE Android code, and how to build the system for a device.
One comment on the XDA-developers forum seems to sum it up nicely:
Android security != Linux security. On stock Android, have you ever noticed how you don’t have to put in a password every time you want to install an app? There isn’t a single Linux distribution out there that I can name where you’re given the ability to modify the system like that without prompting for root or admin privileges. The app gives you a single “Are you sure?” prompt and then it goes about its business.
The fact that apps have the inherent ability to sidestep the standard Linux permissions pretty much breaks all of the functionality of SELinux, so it has to be rebuilt specifically for Android.
Policy, Policy, Policy
According to the SELinux project, SE Android policy sources – the formal specification of who can do what – are located under external/sepolicy. These files are used to generate the following:
- The SELinux kernel policy file itself
- The file_contexts configuration, 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, used to specify the security context of Android properties for permission checking purposes.
- The seapp_contexts configuration, used to label app processes and app package directories.
- The mac_permissions.xml configuration, the middleware MAC (mandatory access control) policy.
Device-specific policy can be specified by defining BOARD_SEPOLICY_DIRS, BOARD_SEPOLICY_UNION and/or BOARD_SEPOLICY_REPLACE variables in a BoardConfig.mk file under the device/<vendor>/<device> or vendor/<vendor>/<device> directories. An example can be found in device/samsung/tuna/BoardConfig.mk, which defines these variables to reference device-specific policy files under device/samsung/tuna/sepolicy. Documentation for per-device policy can be found in external/sepolicy/README.
SE Android features
Detailed, specific features of the latest SE Android reference implementation include:
- Per-file security labelling support for yaffs2,
- Filesystem images (yaffs2 and ext4) labelled at build time,
- Labelling support in the recovery console and updater program,
- Kernel permission checks controlling Binder IPC,
- Labelling of service sockets and socket files created by init,
- Labelling of device nodes created by ueventd,
- Flexible, configurable labelling of apps and app data directories,
- Minimal port of SELinux userspace,
- SELinux support for the Android toolbox,
- JNI bindings for SELinux APIs,
- Userspace permission checks controlling use of the Zygote socket commands,
- Userspace permission checks controlling setting of Android properties,
- Small TE policy written from scratch for Android,
- Confined domains for system services and apps,
- Use of MLS categories to isolate apps.
SE Android availability
The selinuxproject provides an abbreviated example sequence of commands for downloading Android 4.2 with the SE Android modifications.
git clone -b seandroid-4.2 https://bitbucket.org/seandroid/manifests.git
repo init -u https://android.googlesource.com/platform/manifest -b android-4.2.1_r1
cp ../manifests/local_manifest.xml .repo/
Emulation and compatibility
If you want to run SE Android in the Android emulator, you will need a modified kernel with appropriate support for SELinux, writes the SELinux wiki.
In order to run the Android Compatibility Test Suite (CTS) with SE Android, instructions can be found at http://source.android.com/compatibility/
See also… Commercial equivalent
One company working in this area is General Dynamics, which has just announced a partnership with Samsung to incorporate its “GD Protected” technology into Samsung Galaxy devices running Samsung KNOX, which is where we came in…
Think of it as a “hardened” version of Android. More details of GD Protected technol ogy can be found at www.gdc4s.com/gdprotected.
“GD Protected secure mobility solutions deliver unprecedented security for commercial smartphones, tablets and applications, including the data stored on them,” wrties the compnay in the announcement. “Designed for the mobile workforce in government, military and regulated enterprises, General Dynamics’ GD Protected solutions let users securely access restricted and open networks to talk, text and video conference – all while using one commercial smartphone, handset or tablet with the superior user experience people expect.”
Effectively, given Android’s open nature, any organisation could choose to do the work to make Android more inherently secure, but it doesn’t mean it is “SE Android”…
Another company touching this area is Centrify. Samsung’s KNOX system is partly built with Centrify’s Active Directory-based mobile security and cloud identity technology.
Centrify’s press release states:
As part of this OEM agreement, Centrify will help Samsung power the growth of an easy-to-use, developer kit and ISV app ecosystem for Android in the enterprise through the licensing of its Mobile Authentication Services (MAS) Software Development Kit (SDK) into the Samsung for Enterprise (SAFE) SDK Framework. This enables any Android app developer to use this SAFE mobile client SDK within their rich native mobile app to enable “Zero Sign-On” from devices running KNOX to their cloud-based applications. This Zero Sign-On goes beyond traditional SSO for devices enrolled in the Centrify Cloud Service, by allowing users one-click sign-on to enterprise apps without having to enter a username and password.
Note an update as part of Android “KitKat” 4.4 – the company writes (about enhanced security):
Security improvements in Android 4.4, from the community: In Android 4.4, we reinforced the Android sandbox (which prevents applications from extending outside of their own area and damaging other parts of a device) by putting SELinux into enforcing mode, providing one of the strongest security systems available. The core of SELinux, as well as many of the Android specific extensions have been contributed by third-parties through open source, an example of real security improvements from the community you can use today.
See also: Google strengthens Android security muscle with SELinux protection (arstechnica.com)Tags: security