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 principle of least privilege. By default,
unrestricted root is found nowhere in the system due to the
full system SELinux policy. 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. 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. This is why 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 sometimes not apply them at all, especially when it comes 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 customizing 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.
Although, some signature spoofing implementations restrict it to make it less bad such as CalyxOS' implementation which allows only microG to spoof the Play Services signature and nothing else.
Firewalls such as AFWall+ or
Netguard are regularly used on Android to attempt to block network access from a specific app but these
do not reliably work — apps can use IPC to bypass the 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) to make it 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
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 3 or greater and flash
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 the best hardware to use as they have a lot of hardening that other devices lack such as full verified boot with support for custom keys, the Titan M chip, decent SoC exploit mitigations and a strict IOMMU to isolate physical components, fine-grained forward-edge Control-Flow Integrity and ShadowCallStack for the kernel, etc.
Remember that GrapheneOS cannot prevent you from ruining your privacy yourself. You still have to be careful regardless of the operating system.