No, the sky is not falling Chicken Little. We are still safe and Google has not locked us down. Those of us who like write access to the system partition will still be able to do it in the future. At the end of May a patch was committed and merged into the AOSP that builds upon the security of SELinux (Security Enhanced Linux) in the kernel. From Google themselves:
Android uses Security-Enhanced Linux (SELinux) to enforce Mandatory Access Control (MAC) over all processes, even processes running with root/superuser privileges (a.k.a. Linux capabilities)….With SELinux, Android can better protect and confine system services, control access to application data and system logs, reduce the effects of malicious software, and protect users from potential flaws in code on mobile devices.
SELinux for Android is a project designed originally to identify and address critical gaps in the security of Android. It was to limit the damage any malicious apps could do. Using Mandatory Access Control (MAC), SELinux provides a set of security rules that determine the resources accessible by a process. SELinux policy determines whether a process has access to a file, directory, or port. Interestingly, it seems that SELinux is here to stay as Google maintain that for a device to meet the Android Compatibility program must not remove the default SELinux settings.
The new commit by the developers porting SELinux to Android (SEAndroid) aims to take these security measures a step further:
Remove /system write from unconfined
Don’t allow writes to /system from unconfined domains.
/system is always mounted read-only, and no process should
ever need to write there.Allow recovery to write to /system. This is needed to apply OTA
images.
Before you start saying that this is Android becoming closed like iOS is, hold up the page and read a bit more. The patch is the next step in securing Android up for the enterprise community (not long before Android for Work was announced at Google IO). As the commit says, it prevents the user (or any malicious app or user) from writing to the system partition. There are a lot of legitimate root apps (and Xposed modules) that write to the system partition of your device to perform their intended (and non-malicious) function. With the new change that has been merged into the AOSP they will not be able to do so any more. The only way an app or user will be able to write to the system partition will be in the recovery, as that is how OTAs are applied. This is the only justifiable reason for writing to the system according to the security experts.
The above statements will apply to all users who like to run a rooted stock Android device. Read over that last sentence again. Rooted stock users. All of them. Sounds scary but it isn’t really. It still remains to be seen whether Google implement this into their version of Android and it also remains to be seen whether the manufacturers do so as well, although I doubt that they wouldn’t bring this increased security to their phones when it may help them sell a few more to the business/enterprise community. All the manufacturers signing onto Android For Work shows how interested they are in this market.
So how do we get around it? It’s actually pretty easy, for those with unlocked bootloaders but possibly harder on locked devices. All you need is a custom kernel built/compiled without this commit merged into it or it turned off and you will once again be able to write to the system partition. It could be a fully stock kernel except for that one single commit and you will still be able to write to the system. I am assured by a developer friend that this is extremely easy to do and anybody capable of compiling a custom kernel should be able to do with ease.
All we are seeing the the evolution of Android from something that was easily rooted using telnet (G1) to an enterprise-friendly secure device. There are ways around it for those who wish to take the red pill and open up a whole new world of Android but for the vast majority who live with a stock Android device it makes their device and its data much more inherently secure. This can only be a good thing for Android itself given the mostly untapped enterprise market but, depending on where it stops may not be a good thing for those of us who like to tinker with the inner workings of their device’s Android OS. Chainfire, developer of SuperSU , has found other ways Google could make Android more secure which may make root access even harder but Google are yet to implement them. If they do then obtaining root access to your own device becomes a whole new problem.
As Cyanogen himself said a while back, maybe we don’t need root access to perform a lot of these functions. Cyanogen Inc have shown this with the OnePlus One. Without root access I can perform most of the functions of a standard rooted custom rom. For OnePlus to pass the CTS (Compatibility Test Suite) and be able to ship with Google apps they must not ship a device with root access out of the box. Maybe other custom roms will follow suit and head down this path of using system APIs instead of root access eventually.
Sidenote: The commit to AOSP in this post involved an employee of NSA. We will assume it was because he/they are experts on security and not because the NSA are building a backdoor into Android. Remember Android is open source so anyone can take a look at their commits so they wouldn’t be able to get away with doing anything nefarious as creating a backdoor.
The NSA code in Android is safe and secure. No need to worry. It was not merged by a NSA employee. SELinux has been in the mainline Linux kernel since 2.6.
The SEpolicy change and SEpolicy code in general was just written by him and went through review by several Google employees and several Linux developers. NSA employees don’t have +2-Merge rights to AOSP repos so nobody is directly spying on you via SEPolicy via code inserted by them.
*Takes tinfoil hat back off*
Do you think that all this extra security is a good thing for Android? Will you think twice about rooting your device now? Or will you just flash a custom kernel with the system write access turned on?
The argument that restricting user permissions is good for security and necessary for enterprise readiness is ridiculous. Desktop OSes have long been enterprise ready while maintaining user root privileges. The only reason to think otherwise is if you’re a Kool-Aid drinker.
How old is your desktop? It can’t be a Mac or Linux machine from the last decade, or a Windows box after XP, as none of those give you root permission out of the box. If it is Windows, did you turn off UAC and forget?
@piersporter:disqus May have used the wrong semantics in the previous post, but my point is that desktop OSes are considered secure without users having to hack their devices to get root access as Android (and every other mobile OS) requires.
Well since SE-Linux was originally architected and developed by the NSA, I don’t think it changes much to do with trust if any recent commits were also performed by an employee of the NSA. They’ve proved themselves largely untrustworthy and have been caught putting backdoors in open-source algorithms before. That said, implementing SE-Linux is probably a step forward in security for Android IMHO and probably constitutes a step towards better security, even if the original creator’s reputation is tarnished.
Noting what you say regarding the originators of the Linux code that might be being injected into Android, I would call it a reduction in security rather than an improvement. This is because of 2 points: 1. What you point out about the known track record of the mob in putting backdoors into code. 2. Where in Android they are trying to lock down. What’s the betting the NSA want that specific part of Android locked down from users being able to seal shut their backdoor riddled code, simply by the users rooting their devices and replacing the potentially hazardous… Read more »
I see it as an improvement in security in terms of the greatest threat – malware from dubious sources. For this sort of problem, SE-Linux should offer increased security due to the OS being harder to exploit. If the NSA have any backdoors in SE-Linux then it has defied the best security analysts to find so far, so I don’t think any malware authors will be piggy-backing their exploits on top of it any time soon. If you’re more concerned about keeping your data away from the NSA than the usual malware authors, then: A) You are probably a very… Read more »