On January 6, the US National Security Agency (NSA) released the first public release of the Security Enhanced (SE) Android Project, a program designed to find and plug security holes and risks in the Android flavor of Linux. SE Android is based on the NSA’s SELinux, first released in 2000.
SELinux started as a string of security patches to the Linux kernel along with a few utilities to help with access control and damage confinement. One of the key differences between the base Linux kernel and SELinux is the switch to Mandatory Access Control (MAC), a change from the Discretionary Access Control (DAC), which allows users to elevate their permissions to run certain commands as if they were the root user of the system. MAC can be configured system-wide and only allows users minimum access required to do their jobs. This level of security keeps programs and daemons from causing more harm than they would normally be able to if they become compromised. Individual applications can also be “sandboxed,” which means they are kept away from other applications running, isolating them in case one becomes compromised.
As of the 2.6.0-test3 kernel, SELinux was compiled into the base Linux kernel, and no longer requires separate patches or updates. This merging occurred in August of 2003, and SELinux has also seen contributions from Network Associates, Secure Computing Corporation, Trusted Computer Solutions and Tresys.
SE Android was first publicly described at Linux Security Summit 2011. In essence, the NSA is attempting to bring the same access control and damage mitigation measures found in SELinux to the Android Open Source Project. In the Security Summit presentation, a number of known security vulnerabilities were demonstrated and tested against a version of Android running SE Android controls. All exploits failed unless specifically tailored to the particular system, and even in those cases the exploit’s effectiveness was much reduced.
Going forward, the SE Android Project team is looking to incorporate SE Android into Application Layer Security, so it is able to thwart unauthorized access and compromised programs at the application layer instead of only battling at the kernel level.
There’s a lot to do to get SE Android built into the current Android tree, but it certainly seems like the right way to go. With the explosion of applications in the Android market, and some question of why certain applications need access to user information such as the user’s contact list or the ability to access the internet or telephone application when it’s not a facet of the application itself, SE Android controls would be a welcome addition to security-minded Android users. Government entities may find a security-hardened mobile phone operating system enticing to use, as well.
The need for security on the internet and in the mobile space has never been more important. SE Android is looking to bridge the current gap between Android and a secure experience for always-connected communication devices. SE Android won’t make malware a thing of the past on its own, but it will certainly be a welcome edition in the fight against malicious hackers.
Read more about SE Android
While the definition of open usually involves fully crowdsourced piece of software, the fact that Google holds the code until it’s ready for everyday use is about quality. Honeycomb was not released until recently because of the fragmentation of the platform, and Google not wanting to exacerbate the problem. Once Android source goes live, anyone can do anything they like with it, even add to the source tree. I can concede the issue to a point, but I don’t think that Google’s focus on quality should be reason for a low score.
