OEMs still the Achilles heel of Android security, say boffins
Mobe-makers just can't be bothered keeping Google-spawn up to date
Good, but not good enough: that's the verdict of a bunch of researchers who checked out the security model that Google's applied to Android since the Lollipop 5.0 release.
In this Arxiv paper, Elena Reshetova and her collaborators from Finland's Aalto University (with support from Intel) look over the post-Lollipop era, in which (as they note) “every process must be run inside a confined SEAndroid domain with a proper set of access control rules defined”.
The problem, they write, is that while the structure and policy would work well if they were followed, OEMs have room to make implementation mistakes: “OEM modifications can render policies less strict, resulting in a wider attack surface for potential vulnerabilities”, they write.
The errors arise because OEMs aren't coping with turning product around quickly enough to compete, while trying to make sure their implementations comply with the SEAndroid security policy.
Such issues include:
- Overuse of default profiles, which can mean OEM Android versions can point to sensitive resources from untrusted domains;
- Overuse of predefined domains – instead of defining separate domains for each of their apps, OEMs tend to put them in the system_app or platform_app domains, leading to an accumulation of too many apps sharing the same allow rules.
- Forgotten rules – security rules that are either auto-generated or relate to deprecated drivers, hanging around creating vulnerabilities; and
- Dangerous rules – essentially insecurity-by-convenience. Rather than go back and make wholesale changes to the code-base, OEMs ship products with inadequate security policies.
The group has put together an open-source tool, SEAL, which provides policy analysis, policy visualisation, and policy decompilation. ®