Basic Safety Features of Graphene OS

Below are some of the safety features that come with Graphene OS.

Firewall service provided within Graphene OS

Graphene OS enhances Android's integrated firewall, incorporating improvements that have largely been merged upstream. It introduces a user-facing Network permission toggle that blocks both direct and indirect network access for apps, leveraging the standard INTERNET permission for full app ecosystem compatibility. Direct access is blocked at the socket level, while indirect access via OS components like Download Manager is also denied. When the Network permission is revoked, Graphene OS simulates a downed network, preventing apps from attempting connections and saving battery life.

System-Wide Ad-Blocking on Graphene OS:

Recommended Approach: Use domain-based ad-blocking via Private DNS (DNS-over-TLS) by setting a server like AdGuard DNS (dns.adguard-dns.com). This method was once part of Graphene OS but is currently a low-priority feature awaiting reimplementation by contributors. Be aware that ad-blocking can be detected, potentially aiding user fingerprinting, though using a popular service like AdGuard with standard block lists minimizes this risk compared to custom rules.

Ad-Blocking Apps: Graphene OS supports content filtering apps, but they are not recommended due to significant drawbacks. These apps use the VPN service to filter traffic, which conflicts with encryption (e.g., HTTPS). AdGuard's optional HTTPS interception, which requires trusting a local certificate authority, poses security risks and weakens HTTPS, especially since it can't bypass certificate pinning in most apps. Many filtering apps only offer domain-based filtering and require disabling Private DNS, losing its security benefits. Few apps provide their own DNS-over-TLS resolver. Additionally, most ad-blocking apps don’t support actual VPN functionality, forcing users to choose between ad-blocking and VPN use.

RethinkDNS Exception: RethinkDNS is a better option, combining DNS-based filtering with WireGuard VPN support and connection monitoring, avoiding the need to choose between ad-blocking and VPN functionality or relying on risky TLS interception

Bootloader is locked :

Mobiles that are sold from FreedomFone Hub do have their bootloaders locked and is done during set up. Before data is added to a device running Graphene OS, you must lock the bootloader to ensure security, as an unlocked bootloader renders the device insecure. Locking the bootloader wipes all user data, and Graphene OS does not support running the OS with an unlocked bootloader, considering it an incomplete installation.

Google services and Graphene OS

Graphene OS does not include Google apps or services, nor will it ever bundle them, similar to the Android Open Source Project. Instead, it offers a compatibility layer for sandboxed Play services, allowing users to install them as unprivileged, sandboxed apps in specific profiles to control access. Many apps function fully or partially without Play services. For AOSP APIs not tied to Google (e.g., text-to-speech, geocoding), Graphene OS aims to implement open-source alternatives, such as Seedvault for backups, rather than relying on Google services. Ideally, Google would allow Play services to function as regular apps without requiring deep OS integration and special privileges, but until then, Graphene OS will maintain its sandboxed compatibility approach.

Graphene OS and Factory Reset Protection

GrapheneOS does not provide Factory Reset Protection (FRP) as it is considered a theft deterrence feature, not a security feature, and typically relies on tying the device to an online account, like Google’s FRP, which uses a persistent state to lock a wiped device to a Google account. An alternative offline FRP using a seed phrase could be implemented, but it’s a low priority due to minimal security benefits and the risk of bricking devices if users lose their seed phrase or forget their passphrase. Disabling wiping from recovery is another option but is incompatible with planned auto-wipe features and would likely cause more bricked devices, so GrapheneOS will not pursue it. Any future FRP implementation would be low priority to avoid bricking issues, and no support would be offered for bricked devices.

Graphene OS Code Review and Auditing:

Graphene OS, as an open-source project, benefits from continuous external code review by security researchers, companies, and organizations like ANSSI, which use and contribute to its development. The project's well-documented, organized code facilitates thorough and ongoing audits, with public pull requests and issue trackers showcasing review results, such as fixes for issues like false positives in hardened_malloc. Collaboration with other AOSP-based projects like DivestOS and ProtonAOSP further enhances code scrutiny, leading to fixes like a minor Camera app issue that uncovered a serious memory corruption bug in older devices.

Graphene OS maintains clean patch sets on top of AOSP, regularly refined for clarity and portability, making reviews easier using tools like git range-diff. Standalone projects like Auditor and AttestationServer are designed for minimalism and auditability. Upstream contributions, such as the CONFIG_FORTIFY_SOURCE feature for the Linux kernel, undergo rigorous external review, resulting in significant improvements and bug fixes in GCC, Clang, and Android. This ongoing, collaborative review process, driven by familiarity with the codebase, ensures robust security and compatibility, far surpassing the value of shallow, one-time audits.

USB C and Pogo Pin protection

Graphene OS provides a robust USB-C port and pogo pins protection feature to secure devices against attacks when the OS is booted, labelled as USB-C port for devices without pogo pins. It offers five modes: Off, Charging-only, Charging-only when locked, Charging-only when locked except before first unlock, and On. The default, Charging-only when locked, significantly reduces the attack surface by blocking new USB connections immediately after locking at both hardware (via USB controller) and OS (kernel) levels, disabling data lines and USB-C alternate modes like DisplayPort once existing connections end.

Unlike Android’s standard USB HAL toggle, which only limits high-level USB handling in the OS without blocking new connections or disabling data lines and alternate modes at the hardware level, Graphene OS’s implementation is more secure. It uses a two-phase approach for its Charging-only when locked modes, ensuring no new connections are allowed while gracefully handling existing ones. The Off mode maximizes security by disabling both data and charging, eliminating risks from the USB controller and protocols like USB-PD, but charging remains available when the device is off or in firmware modes like fastboot, recovery, or charging.

Handling of Exploits

Hardened App Runtime:

Secure App Spawning: Prevents sharing of address space layout and secrets across apps.

Hardened libc: Defends against common memory corruption vulnerabilities.

Hardened malloc: Uses modern hardware for robust heap memory protection, reducing sensitive data lifetime. Features include out-of-line metadata, separate memory regions with random bases, deterministic invalid free detection, zero-on-free with write-after-free checks, delayed memory reuse via quarantines, fine-grained randomization, and memory-tagged slab allocations for probabilistic and deterministic overflow/use-after-free detection. It’s portable, adopted by projects like secureblue, and influences musl’s next-gen malloc.

Hardware Protections: On ARMv9, enables Branch Target Identification (BTI) and Pointer Authentication Code (PAC) for userspace code, plus well-defined signed integer overflow in C/C++.

Exploit Protection Toggles: Allows disabling dynamic code loading (memory/storage) and WebView JIT for user apps, with notifications for blocked attempts. Android JIT is replaced with ahead-of-time compilation; V8 JavaScript JIT is disabled by default in Vanadium with per-site exceptions.

Hardened Kernel:

Memory Protections: Uses 4-level page tables on arm64 for larger address space and higher entropy ASLR. Kernel heap (slub) and allocators use random canaries, zero-on-free, and memory tagging for overflow/use-after-free detection. Memory is zeroed on release and during early boot to eliminate residual data.

Attack Surface Reduction: Disables features like perf and ptrace unless needed, enforces kernel module signing with RSA 4096/SHA256 keys, and uses lockdown mode for kernel-userspace boundary enforcement.

Additional Hardening: Enables upstream hardening features (e.g., linux-hardened project contributions), Clang type-based CFI, BTI, ShadowCallStack, and PAC on ARMv9, plus integrity checks for kernel data structures.

Patches and Fixes

GrapheneOS rapidly and securely delivers the latest Linux kernel LTS point releases for devices with Generic Kernel Image (GKI) support, such as 6th and 7th generation Pixel phones. As of November 6, 2023, GrapheneOS uses Linux 5.10.199, significantly ahead of the stock Pixel OS on Linux 5.10.157 (from December 2022) with fewer patches. This provides hundreds of additional kernel patches, including critical security fixes, not yet in the stock OS, due to Google's slower quarterly LTS update cycle.

GrapheneOS actively identifies and reports dozens of vulnerabilities in the Android codebase and Pixel-specific components, including missed patches in device-specific codebases. While prioritizing systemic privacy and security enhancements, addressing individual vulnerabilities remains a key focus.

Sandboxed Google Play in GrapheneOS:

Graphene OS offers a compatibility layer that allows users to install and use official Google Play apps within the standard Android app sandbox, without granting them special privileges or access, unlike typical implementations where Google Play bypasses the sandbox and receives highly privileged access. These apps are installed in specific user or work profiles, accessible only within those profiles, and operate like regular apps with no special capabilities. They cannot access other apps' data without explicit user consent via standard permissions or profile data access.

The compatibility layer ensures near-complete functionality for Google Play-dependent apps, supporting features like in-app purchases, Play Store services, Play Asset Delivery, Play Feature Delivery, and app license checks. Most Play services, including dynamically downloaded modules and Google Play Games, work fully, though some privileged functionalities are unavailable as they cannot be adapted to the sandboxed environment. Location requests are rerouted to Graphene OS’s reimplementation of the Play geolocation service by default, but users can opt to use Google’s network location service instead. The Play Store supports standard app installation, updates, and uninstallation, including Android 12+ unattended updates, with user authorization required for each action.

Wifi safety

GrapheneOS enhances privacy by implementing per-connection MAC randomization by default, a more private approach than Android’s standard persistent per-network random MAC. It flushes DHCP client state before reconnecting to networks to prevent device identification. Additionally, GrapheneOS fixes serious flaws in the Linux kernel’s IPv6 privacy address implementation, which could otherwise allow device tracking across networks. These fixes are applied for devices prior to the Pixel 6, as newer models benefit from upstream Linux kernel improvements, but older kernel branches still require GrapheneOS’s patches.

Two-factor fingerprint unlock

GrapheneOS introduces an option to require a second-factor PIN after fingerprint authentication on the lockscreen to fully unlock the device. This enhances security by allowing a strong passphrase as the primary unlock method, while using fingerprint and a short PIN for convenient secondary unlocking. Incorrect PIN entries count toward the standard attempt limit.

Support for longer passwords

GrapheneOS supports setting longer passwords by default: 128 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

GrapheneOS’s auto-reboot feature enhances security by rebooting locked devices after a set period, ensuring data is at rest. A countdown timer starts when the device locks, rebooting if no successful unlock occurs before it expires. Unlocking any profile cancels the timer. The default timer is 18 hours, adjustable from 10 minutes to 72 hours, or can be disabled. The feature doesn’t apply in the "Before First Unlock" state to prevent continuous reboots. Implemented in the init process, it’s resistant to bypass via system crashes, as an init crash triggers a kernel panic and reboot

Clearing data from memory

GrapheneOS enhances security by adding zeroing of freed memory to both userspace and kernel allocators, which clears sensitive data quickly and protects against exploits. This complements Android’s memory compaction for cached and background apps, triggering full garbage collection (GC) to free memory, which is then zeroed. When the device is locked, GrapheneOS triggers full compacting GC for SystemUI and system_server processes, clearing unused memory immediately, building on Android’s approach to clear PIN/password remnants after unlocking. The kernel page allocator zeroing ensures unreferenced data is wiped. Additionally, GrapheneOS modifies reboot processes to ensure memory is freed and cleared by its zeroing features, aligning with its auto-reboot feature to secure data at rest.

Duress password

GrapheneOS provides users with the ability to set a duress PIN/Password that will irreversibly wipe the device (along with any installed eSIMs) once entered anywhere where the device credentials are requested (on the lockscreen, along with any such prompt in the OS).

The wipe does not require a reboot and cannot be interrupted. It can be set up at Settings > Security & privacy > Device unlock > Duress Password in the owner profile. Duress PIN is solely used for PIN entry and duress password is solely used for password entry. Both a duress PIN and password are mandatory to enable the feature to account for different profiles that may have different unlock methods. Duress PIN will also wipe the device when entered as the two-factor fingerprint unlock PIN but not currently when entered as the SIM PIN.

Note that if the duress PIN/Password is the same as the actual unlock method, the actual unlock method always takes precedence, and therefore no wipe will occur.

User Profiles

Graphene OS enhances Android’s user profiles, which are isolated workspaces with separate apps, data, and encryption keys based on each profile’s lock method. Apps within a profile can only communicate with each other (with mutual consent) and cannot access other profiles’ apps or data. Graphene OS improves this feature and plans further enhancements for easier profile switching and monitoring.

Key Improvements:

More User Profiles: Increases the secondary user profile limit to 32 (31 + guest) from Android’s 4 (3 + guest).

End Session: Allows logging out of profiles without a device manager, deactivating apps and purging encryption keys from memory, securing data at rest.

Disabling App Installation: Adds a toggle in user management settings to block secondary users from installing apps, configurable by the Owner profile.

Improved Install Available Apps: Enables the Owner user to install apps in secondary profiles without redownloading, supporting the app installation toggle.

Notification Forwarding: Allows notifications from background profiles to be forwarded to the active profile, with forwarding disabled by default but configurable per profile, displayed in a standard local notification channel.

These enhancements make user profiles more flexible, secure, and user-friendly on Graphene OS.