#GrapheneOS is very distinct from other Android distributions and OEM configurations. There is a litany of Linux kernel and Android Runtime hardening changes and features powering GrapheneOS. This is very significant but often overlooked because most changes aren't visible to the end user.
The leading example of this is hardened_malloc, the hardened memory allocator used in GrapheneOS to protect against memory corruption vulnerabilities. You can find a technical article about it by Synacktiv, a French cyber security company:
Hardening in GrapheneOS are built on closing out commonly exploited attack surfaces, substituting them with more secure replacements, or giving them stronger security defaults.
If you are a blue teamer you'll already be familiar with the Pyramid of Pain:
For newcomers, this model is a layered pyramid that ranks indicators of compromise by a linear level of difficulty and cost for the threat actor to evade security measures to perform an attack; The bottom of the pyramid being very easy and trivial for the threat actor to change and the top being tough.
This model opens newcomers on how good security strategy is built: Techniques and capabilities over individual actors. Closing out tactics, techniques and procedures are far more important than blocking an IP address or a file hash. You want to protect against a type of attack, not against a particular actor who performs them.
The point of having extensive hardening features is that we need to ensure vulnerabilities that would affect Android are benign, harder to exploit or patched in GrapheneOS before they can be exploited. Android distributions carry the weight of vulnerabilities from upstream. To reduce that weight, we need to make sure a highly sophisticated exploit developer would have to uniquely design their exploit to target GrapheneOS, should they be able to at all.
Without that, GrapheneOS wouldn't be special. It would not be sensible to claim it is more security and privacy focused than Android if it was able to be exploited through the exact same mechanisms with little or no effort needed to port. An Android distribution that is just Android without Google services is mostly as exploitable as Android. Something that is "DeGoogled" (I don't use the term, it's Reddit tier buzzword nonsense) may not necessarily be safer to use either.
To earn the title of being hardened it needs more, but this isn't ever implemented well enough. Projects that have done so to the best of their ability also have died (DivestOS).
Our hardening features are available outside of GrapheneOS. Leading example of this is secureblue, a security hardened Linux distribution (https://secureblue.dev/) which is using hardened_malloc and Vanadium inspired chromium browser. A business also sells hardened Rocky Linux supporting hardened_malloc. If you are a maintainer of a leading project then implementing our hardening features and supporting is strongly encouraged.
Synacktiv
Exploring GrapheneOS secure allocator: Hardened Malloc
Exploring GrapheneOS secure allocator: Hardened Malloc
For newcomers, this model is a layered pyramid that ranks indicators of compromise by a linear level of difficulty and cost for the threat actor to evade security measures to perform an attack; The bottom of the pyramid being very easy and trivial for the threat actor to change and the top being tough.
This model opens newcomers on how good security strategy is built: Techniques and capabilities over individual actors. Closing out tactics, techniques and procedures are far more important than blocking an IP address or a file hash. You want to protect against a type of attack, not against a particular actor who performs them.
The point of having extensive hardening features is that we need to ensure vulnerabilities that would affect Android are benign, harder to exploit or patched in GrapheneOS before they can be exploited. Android distributions carry the weight of vulnerabilities from upstream. To reduce that weight, we need to make sure a highly sophisticated exploit developer would have to uniquely design their exploit to target GrapheneOS, should they be able to at all.
Without that, GrapheneOS wouldn't be special. It would not be sensible to claim it is more security and privacy focused than Android if it was able to be exploited through the exact same mechanisms with little or no effort needed to port. An Android distribution that is just Android without Google services is mostly as exploitable as Android. Something that is "DeGoogled" (I don't use the term, it's Reddit tier buzzword nonsense) may not necessarily be safer to use either.
To earn the title of being hardened it needs more, but this isn't ever implemented well enough. Projects that have done so to the best of their ability also have died (DivestOS).
Our hardening features are available outside of GrapheneOS. Leading example of this is secureblue, a security hardened Linux distribution (https://secureblue.dev/) which is using hardened_malloc and Vanadium inspired chromium browser. A business also sells hardened Rocky Linux supporting hardened_malloc. If you are a maintainer of a leading project then implementing our hardening features and supporting is strongly encouraged.
Here is how the apps resize.
This will continue to be improved in the Android 16 QPR2 based release of GrapheneOS on the way and possibly be available outside of a developer option in Android 17.