What Is Graphene Os And How Does It Work



This is a private and secure mobile operating system with Android app compatibility. Developed as a non-profit open source project.

GrapheneOS is a privacy and security focused mobile OS with Android app compatibility developed as a non-profit  open source project. It’s focused on the research and development of privacy and security technology including substantial improvements to sandboxing, exploit mitigations and the permission model. It was founded in 2014 and was formerly known as CopperheadOS.

GrapheneOS improves the privacy and security of the OS from the bottom up. It deploys technologies to mitigate whole classes of vulnerabilities and make exploiting the most common sources of vulnerabilities substantially more difficult. It improves the security of both the OS and the apps running on it. The app sandbox and other security boundaries are fortified. GrapheneOS tries to avoid impacting the user experience with the privacy and security features. Ideally, the features can be designed so that they’re always enabled with no impact on the user experience and no additional complexity like configuration options. It’s not always feasible, and GrapheneOS does add various toggles for features like the Network permission, Sensors permission, restrictions when the device is locked (USB peripherals, camera, quick tiles), etc. along with more complex user-facing privacy and security features with their own UX.

The  features page provides an overview of the substantial privacy and security improvements added by GrapheneOS to the Android Open Source Project (AOSP).

Official releases are available on the reease page and installation instructions are on the install page

GrapheneOS also develops various apps and services with a focus on privacy and security. Vanadium is a hardened variant of the Chromium browser and WebView specifically built for GrapheneOS. GrapheneOS also includes our minimal security-focused PDF Viewer, our hardware-based Auditor app / attestation service providing local and remote verification of devices, our modern privacy / security focused camera app, and the externally developed Seedvault encrypted backup which was initially developed for inclusion in GrapheneOS.


These are the features of GrapheneOS beyond what’s provided by version 12.1 of the Android Open Source Project. It only covers our improvements to AOSP and not baseline features. This section doesn’t list features like the standard app sandbox, verified boot, exploit mitigations (ASLR, SSP, Shadow Call Stack, Control Flow Integrity, etc.), permission system (foreground-only and one-time permission grants, scoped file access control, etc.) and so on but rather only our improvements to modern Android. We plan on providing a separate page listing the improvements we’ve contributed to Android since those features aren’t listed here despite being a substantial portion of our overall historical work.

Defending against vulnerabilities

GrapheneOS is heavily focused on protecting users against attackers exploiting unknown (0 day) vulnerabilities. Patching vulnerabilities doesn’t protect users before the vulnerability is known to the vendor and has a patch developed and shipped.

Unknown (0 day) vulnerabilities are much more widely used than most realize to exploit users not just in targeted attacks but in broad deployments. Project Zero maintains  a spreadsheet tracking zero day exploitation detected in the wild. This is only a peek into what’s happening since it only documents cases where the attackers were caught exploiting users, often because the attacks are not targeted but rather deployed on public websites, etc.

The first line of defense is attack surface reduction. Removing unnecessary code or exposed attack surface eliminates many vulnerabilities completely. GrapheneOS avoids removing any useful functionality for end users, but we can still disable lots of functionality by default and require that users opt-in to using it to eliminate it for most of them. An example we landed upstream in Android is disallowing using the kernel’s profiling support by default, since it was and still is a major source of Linux kernel vulnerabilities. Profiling is now only exposed to apps for developers who enable developer tools, enable the Android Debug Bridge (ADB) and then use profiling tools via ADB. It’s also only enabled until the next boot. This isn’t listed below since it’s one of the features we got implemented in Android itself.

The next line of defense is preventing an attacker from exploiting a vulnerability, either by making it impossible, unreliable or at least meaningfully harder to develop. The vast majority of vulnerabilities are well understood classes of bugs and exploitation can be prevented by avoiding the bugs via languages/tooling or preventing exploitation with strong exploit mitigations. In many cases, vulnerability classes can be completely wiped out while in many others they can at least be made meaningfully harder to exploit. Android does a lot of work in this area and GrapheneOS has helped to advance this in Android and the Linux kernel. It takes an enormous amount of resources to develop fundamental fixes for these problems and there’s often a high performance, memory or compatibility cost to deploying them. Mainstream operating systems usually don’t prioritize security over other areas. GrapheneOS is willing to go further and we offer toggles for users to choose the compromises they prefer instead of forcing it on them. In the meantime, weaker less complete exploit mitigations can still provide meaningful barriers against attacks as long as they’re developed with a clear threat model. GrapheneOS is heavily invested in many areas of developing these protections: developing/deploying memory safe languages / libraries, static/dynamic analysis tooling and many kinds of mitigations.

The final line of defense is containment through sandboxing at various levels: fine-grained sandboxes around a specific context like per site browser renderers, sandboxes around a specific component like Android’s media codec sandbox and app / workspace sandboxes like the Android app sandbox used to sandbox each app which is also the basis for user/work profiles. GrapheneOS improves all of these sandboxes through fortifying the kernel and other base OS components along with improving the sandboxing policies.

Preventing an attacker from persisting their control of a component or the OS / firmware through verified boot and avoiding trust in persistent state also helps to mitigate the damage after a compromise has occurred.

Remote code execution vulnerabilities are the most serious and allow an attacker to gain a foothold on device or even substantial control over it remotely. Local code execution vulnerabilities allow breaking out of a sandbox including the app sandbox or browser renderer sandbox after either compromising an app / browser renderer remotely, compromising an app’s supply chain or getting the user to install a malicious app. Many other kinds of vulnerabilities exist but most of what we’re protecting against falls into these 2 broad categories.

The vast majority of local and remote code execution vulnerabilities are memory corruption bugs caused by memory unsafe languages or rare low-level unsafe code in an otherwise memory safe language. Most of the remaining issues are caused by dynamic code execution/loading features. Our main focus is on preventing or raising the difficult of exploiting memory corruption bugs followed by restricting dynamic code execution both to make escalation from a memory corruption bug harder and to directly mitigate bugs caused by dynamic code loading/generation/execution such as a JIT compiler bug or a plugin loading vulnerability.

Attack Surface Reduction

  • Greatly reduced remote, local and proximity-based attack surface by stripping out unnecessary code, making more features optional and disabling optional features by default (NFC, Bluetooth, etc.), when the screen is locked (connecting new USB peripherals, camera access) and optionally after a timeout (Bluetooth, Wi-Fi)
  • Option to disable native debugging (ptrace) to reduce local attack surface (still enabled by default for compatibility)


GrapheneOS includes fixes for many vulnerabilities not yet fixed in Android. On modern devices with Generic Kernel Image (GKI) support, we update the kernel to the latest stable GKI release many months before the stock OS gets the update. This means we’re shipping hundreds of fixes not included in the stock OS including many security fixes. We also backport more fixes on top of this for the kernel and for other components too.

We often find new vulnerabilities ourselves and report them upstream. We’ve reported dozens of vulnerabilities for both the generic Android codebase and also for Pixels specifically. We also often find missed patches which were supposed to be included but were missed, especially when there are device specific components with partially shared but separate codebases for different devices.

Our overall approach is to focus on systemic privacy and security improvements but fixing individual vulnerabilities is still very important.

Network Permission Toggle

GrapheneOS adds a Network permission toggle for disallowing both direct and indirect access to any of the available networks. The device-local network (localhost) is also guarded by this permission, which is important for preventing apps from using it to communicate between profiles. Unlike a firewall-based implementation, the Network permission toggle prevents apps from using the network via APIs provided by the OS or other apps in the same profile as long as they’re marked appropriately.

The standard INTERNET permission used as the basis for the Network permission toggle is enhanced with a second layer of enforcement and proper support for granting/revoking it on a per-profile basis.

Sensors permission Toggle

Sensors permission toggle: disallow access to all other sensors not covered by existing Android permissions (Camera, Microphone, Body Sensors, Activity Recognition) including an accelerometer, gyroscope, compass, barometer, thermometer and any other sensors present on a given device. To avoid breaking compatibility with Android apps, the added permission is enabled by default.

Wifi Privacy

GrapheneOS supports per-connection MAC randomization and enables it by default. This is a more private approach than the standard persistent per-network random MAC used by modern Android.

When the per-connection MAC randomization added by GrapheneOS is being used, DHCP client state is flushed before reconnecting to a network to avoid revealing that it’s likely the same device as before.

GrapheneOS also applies fixes for serious flaws with the Linux kernel IPv6 privacy address implementation which allow using it as an identifier not just for connections to the same network but also across different networks. We don’t need to apply these changes for the Pixel 6 and later since this was fixed in the Linux kernel upstream, but hasn’t been backported to earlier kernel LTS branches so we still need to take care of it there.

Supports longer passwords

GrapheneOS supports setting longer passwords by default: 64 characters instead of 16 characters. This avoids the need to use a device manager to enable this functionality.

This feature allows users to make use of diceware passwords if they don’t want to depend on the security of the secure element which provides very aggressive throttling and offers a high level of security even for a random 6 digit PIN.

Auto Reboot

Option to enable automatically rebooting the device when no profile has been unlocked for the configured time period to put the device fully at rest again.

More Secure Finger Print Unlock

GrapheneOS improves the security of the fingerprint unlock feature by only permitting 5 total attempts rather than implementing a 30 second delay between every 5 failed attempts with a total of 20 attempts. This doesn’t just reduce the number of potential attempts but also makes it easy to disable fingerprint unlock by intentionally failing to unlock 5 times with a different finger.

GrapheneOS also adds support for using the fingerprint scanner only for authentication in apps and unlocking hardware keystore keys by toggling off support for unlocking. This feature already existed for the standard Android face unlock feature.

Improved User Profiles

Android’s user profiles are isolated workspaces with their own instances of apps, app data and profile data (contacts, media store, home directory, etc.). Apps can’t see the apps in other user profiles and can only communicate with apps within the same user profile (with mutual consent with the other app). Each user profile has their own encryption keys based on their lock method. They’re a great fit for GrapheneOS with a lot of room for improvement.

GrapheneOS provides improvements to user profile functionality and is working on further improvements to make switching between them and monitoring other profiles much more convenient.

Drop your comment


Author: refuge_2020

Leave a Reply

Your email address will not be published. Required fields are marked *