By default, Android has a strong security model and incorporates full system SELinux policies, strong app sandboxing, full verified boot, modern exploit mitigations like fine-grained, forward-edge Control Flow Integrity and ShadowCallStack, widespread use of memory-safe languages (Java / Kotlin) and more. As such, this article explains common ways in which people worsen the security model rather than criticisms of the security model itself.
Unlocking the bootloader in Android is a large security risk. It disables verified boot, a fundamental part of the security
model. Verified boot ensures the integrity of the base system and boot chain to prevent
evil maid attacks and malware persistence.
Contrary to common assumptions, verified boot is not just important for physical security — it prevents the persistence
of any tampering with your system, be it from a physical attacker or a malicious application that has managed to
hook itself into the operating system. For example, if a remote attacker has managed to exploit the system and gain high
privileges, verified boot would revert their changes upon reboot and ensure that they cannot persist.
Rooting your device allows an attacker to easily gain extremely high privileges. Android's architecture is built
upon the principle of least privilege. By default,
only around 6 processes run as the root
user on a typical Android device, and even those are still heavily constrained via the full system SELinux policy. Completely unrestricted root is found
nowhere in the operating system; even the init system does not have unrestricted root access. Exposing privileges far
greater than any other part of the OS to the application layer is not a good idea.
It does not matter if you have to whitelist apps that have root — an attacker can fake user input by, for example,
clickjacking, or they can exploit vulnerabilities in apps that
you have granted root to. Rooting turns huge portions of the operating system into root attack surface; vulnerabilities
in the UI layer — such as in the display server, among other things — can now be abused to gain complete root access. In
addition, root fundamentally breaks verified boot and other security features by placing excessive trust in persistent
state. By rooting your device, you are breaking Android's security model and adding further layers
of trust where it is inappropriate.
A common argument for rooting is that Linux allows root, but this does not account for the fact that the average
desktop Linux system does not have a security model like Android does. On the usual Linux system, gaining root is extremely easy, hence Linux hardening procedures often involve
restricting access to the root account.
The majority of custom ROMs severely weaken the security model by disabling verified boot, using userdebug builds, disabling SELinux and various other issues. Furthermore, you are also usually at the mercy of the maintainer to apply security updates properly. Certain ROMs often apply security patches late, or in some cases, not at all. The latter especially applies to firmware patches.
A common ROM that has many of these issues is LineageOS:
This is a non-exhaustive list. There are more issues than just those listed above. LineageOS (and most other custom ROMs) are focused on customising the device and not privacy or security. Of course, you could build LineageOS yourself to fix many of these issues, but most users will not be capable of doing so.
MicroG is a common alternative to Google Play Services. It is often used to get rid
of Google's tracking, but most people do not realise that this can potentially worsen security, as
it requires signature spoofing
support, which allows apps to request to bypass signature verification. This subverts the security model and
breaks the application sandbox as an app can now masquerade itself as another app to gain access to the app's files.
In a system with signature spoofing, it is impossible to know anything — there is no way to trust that an application
is genuinely what it claims to be, and it is impossible to build a strong security model upon this.
Although some signature spoofing implementations can restrict access to this functionality to reduce the risk by, for
example, allowing only microG to spoof the Play Services signature and nothing else.
Firewalls, such as AFWall+ or
Netguard, are regularly used on Android to attempt blocking network access from a specific app, but these
do not reliably work — apps can use IPC to bypass such restrictions. If you cut off network access to an app, it
will not prevent the app from sending an
intent to another app (such as the browser) for it to make the same connection. Many apps already do this
unintentionally whilst using APIs such as the download manager.
The most effective way to block network access is to revoke the INTERNET permission from the app
like
GrapheneOS allows you to do. This prevents abusing OS APIs to initiate network connections, as they contain checks
for that permission, one example of which is the aforementioned download manager. You should also run the app in its
own user or work profile to ensure that it cannot abuse third party apps either.
The best option for privacy and security on Android is to get a Pixel 4 or greater and flash
GrapheneOS. GrapheneOS does not contain any tracking unlike the stock OS on most devices. Additionally, GrapheneOS
retains the baseline security model whilst improving upon it with substantial
hardening enhancements — examples of which include a hardened
memory allocator, hardened C library, hardened kernel, stricter SELinux policies and more.
Pixel devices are also the best hardware to use, as they implement a significant amount of security hardening that most
other devices lack. Examples of this include:
Remember that GrapheneOS cannot prevent you from ruining your privacy yourself. You still have to be careful regardless of the operating system.
Go back