Android 4.3 came out about a week ago and it’s brought SELinux to the operating system. Now, maybe it’s just me, but I feel this is a massive waste of resources. SELinux is going to take a very long time to get working properly (right now if you set it to enforce the system won’t boot, I believe), probably months, and the benefits are not significant.
SELinux is an LSM used to confine services and users, implementing Least Privilege on the system. But attacks on Android have often leveraged kernel exploits, something that SELinux simply doesn’t address. Where SELinux comes in handy is securing services, and preventing an attacker from abusing that service.
So I think the real question is… how much is this hurting Android security? Because SELinux is addressing issues that aren’t so considerable, and the amount of work is absolutely quite high.
Given that Grsecurity/ PaX have ported their main and most important features (ex: UDEREF) to ARM, I would imagine that implementing those features would have significantly less cost, while providing a very high level of security. There are numerous Grsecurity features that have been ported, and should work on Android, and they would make attacking both services and the kernel considerably more difficult.
Beyond that, implementing a MAC system before you harden the kernel is not the most sensible approach. Your MAC relies entirely on the kernel, so protection of the kernel should be the priority. An exploit in an SELinux service will lead to confinement, but on a weak kernel an attacker can break out easily using local kernel escalation. So it makes sense to focus on the kernel itself before you try to have it enforce policies.
Grsecurity also leverages user restrictions well, with a multitude of features (like TPE partial restriction) that apply generically to user accounts. These features would layer beautifully with Android’s own security model, which is heavily reliant on users and groups.
So while we wait for months for a working SELinux profile for Android, we could have significant advances in Android security very quickly if the focus were changed to projects like Grsecurity.
SELinux also fails to deal with Android’s other security issue – apps requesting privileges that they don’t need, and shouldn’t have. For example, Angry Birds asks for GPS and all sorts of other information but you absolutely don’t need that to play the game. OpenPDroid addresses this by allowing the user to remove arbitrary permissions from apps. SELinux does not address this (as it works at the Linux layer, not the Java layer).
OpenPDroid is a framework that already exists. Just as with Grsecurity it would likely not take nearly as long to implement it compared to implementing SELinux.
So focusing on SELinux means less focus on projects that would take less time and provide a higher level of (more relevant) security.