You can set it up before or after install.
Note certain features like duress password will erase your eSIM if triggered, if you ever plan to use it
1. Use the GrapheneOS web installer and follow the instructions. Other guides will be out of date.
2. No, same applies for eSIMs.
3. That's your choice. Some use their personal ones, some buy SIMs privately, some don't use them. A SIM isn't required to use GrapheneOS.
#GrapheneOS version 2025021100 released.
See the changes:
• kernel (5.10, 5.15, 6.1, 6.6): zero memory in early boot in case it wasn't zeroed by the OS as part of a clean reboot or shutdown since there isn't fully encrypted RAM with a per-boot key yet (early boot zeroing is implemented by Pixel boot firmware since April 2024 for booting into fastboot mode but not booting into the OS since they only partially implemented our January 2024 reset attack protection proposal, so we need to handle the OS part ourselves)
• kernel (6.1): add back revert for upstream Linux kernel fix which was reapplied in our 2025020200 release without any reports of issues for days because it has been found to break DisplayPort alternate mode on 9th generation Pixels
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.128
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.76
• kernel (Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold): backport Wi-Fi driver patch from Android 15 QPR2 Beta 3 in an attempt to avoid a rare invalid read-after-free detected by hardware memory tagging
• Launcher: add 4x5 grid option
• Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold: stop enabling safe media volume with US carriers to match having it globally disabled for other devices
• remove infrastructure for our legacy software-based USB peripheral blocking since we've replaced it with a far better feature using both hardware and software USB connection/data blocking across all supported devices
• Camera: update to version 78
Click the settings on the bar on the top left and enable JavaScript JIT.
The functionality provided by Google's new Android System SafetyCore app available through the Play Store is covered here:
https://security.googleblog.com/2024/10/5-new-protections-on-google-messages.html
Neither this app or the Google Messages app using it are part of #GrapheneOS and neither will be, but GrapheneOS users can choose to install and use both. Google Messages still works without the new app.
The app doesn't provide client-side scanning used to report things to Google or anyone else. It provides on-device machine learning models usable by applications to classify content as being spam, scams, malware, etc. This allows apps to check content locally without sharing it with a service and mark it with warnings for users.
It's unfortunate that it's not open source and released as part of the Android Open Source Project and the models also aren't open let alone open source. It won't be available to GrapheneOS users unless they go out of the way to install it.
We'd have no problem with having local neural network features for users, but they'd have to be open source. We wouldn't want anything saving state by default. It'd have to be open source to be included as a feature in GrapheneOS though, and none of it has been so it's not included.
Google Messages uses this new app to classify messages as spam, malware, nudity, etc. Nudity detection is an optional feature which blurs media detected as having nudity and makes accessing it require going through a dialog.
Apps have been able to ship local AI models to do classification forever. Most apps do it remotely by sharing content with their servers. Many apps have already have client or server side detection of spam, malware, scams, nudity, etc.
Classifying things like this is not the same as trying to detect illegal content and reporting it to a service. That would greatly violate people's privacy in multiple ways and false positives would still exist. It's not what this is and it's not usable for it.
GrapheneOS has all the standard hardware acceleration support for neural networks but we don't have anything using it. All of the features they've used it for in the Pixel OS are in closed source Google apps. A lot is Pixel exclusive. The features work if people install the apps.
Content moderation likely. We use Matrix for all the internal matters but Matrix is ripe with abuse and lack of moderation, notably CSAM, spam and more. It is much worse when its a larger room like ours. We have a Discord as one of the optional communication platforms because of that.
Discord is the most popular of the support channel platforms with our users likely for the same reason. We block bridging images and media to other platforms.
Discord just has extremely good moderation tools and the privacy is usually a non-issue for large channels because they are being monitored or are even accessible by people without using Discord at all. GrapheneOS' matrix channels can be viewed by web viewers without an account, for instance.
In April 2024, Pixels shipped a partial implementation of our January 2024 proposal for firmware-based reset attack protection. Fastboot mode now zeroes RAM before enabling USB. This successfully wiped out the After First Unlock state exploit capabilities of two commercial exploit tools for the stock OS.
Several other improvements were made based on our January 2024 vulnerability reports and proposals including an implementation of wiping data before rebooting when a wipe is triggered. We shipped an improved version of this for our duress PIN/password feature before the feature shipped for Android.
We made massive improvements in #GrapheneOS to defend against these attacks since January 2024.
For ARMv9 devices, we greatly improved our hardware memory tagging implementation in hardened_malloc, deployed it for the Linux kernel allocators and greatly expanded the use of PAC and BTI across the OS.
We replaced our decade old feature for blocking new USB peripherals while locked with a greatly expanded and far more secure feature. The new approach blocks USB-C connections and USB-C data at a hardware level with expanded software-based blocking as a fallback.
We started deploying RANDSTRUCT for the kernel, which will eventually be used to have multiple possible struct memory layouts for each device model chosen randomly at boot. Our work on reducing kernel attack surface also continued. We plan to focus more on Linux kernel security going forward.
Our locked device auto-reboot feature from 2021 was replaced with a more secure approach preventing bypasses via crashes. It also avoids chain reboots without introducing a security weakness which makes low timer values such as the minimum 10 minutes far more usable.
We shipped our 2-factor fingerprint unlock feature planned since 2015. It allows people to avoid reliance on secure element security with a strong passphrase while keeping convenience. Fingerprint + scrambled PIN also defends well against being recorded while unlocking.
Several more major improvements specifically against the physical data extraction attack vector are planned. Our next release adds an implementation of zeroing RAM at boot in the kernel to match what fastboot mode does. We also plan to add a toggle for essentially toggling off Device Encrypted data.
Secureblue is a security-focused desktop Linux operating system.
Features
Exploit mitigation:
Installing and enabling GrapheneOS' hardened_malloc globally, including for flatpaks.
Installing our chromium-based browser Trivalent, which is inspired by Vanadium.
SELinux-restricted unprivileged user namespaces
Setting numerous hardened sysctl values details
Sets numerous hardening kernel arguments
Configure chronyd to use Network Time Security (NTS) using chrony config from #GrapheneOS
Set opportunistic DNSSEC and DNSOverTLS for systemd-resolved
Installing usbguard and providing ujust commands to automatically configure it
Filling holes in the linux security posture
Remove SUID-root from numerous binaries, replacing functionality using capabilities, and remove sudo, su, and pkexec entirely in favor of run0
Disable Xwayland by default (for GNOME, Plasma, and Sway images)
Mitigation of LD_PRELOAD attacks via ujust toggle-bash-environment-lockdown
Disable install & usage of GNOME user extensions by default
Disable KDE GHNS by default
Removal of the unmaintained and suid-root fuse2 by default
Disabling unprivileged user namespaces by default for the unconfined domain and the container domain
Security by default:
Disabling all ports and services for firewalld
Use HTTPS for all rpm mirrors
Set all default container policies to reject, signedBy, or sigstoreSigned
Enabling only the flathub-verified remote by default
Reduce information leakage:
Adds per-network MAC randomization
Disabling coredumps
Attack surface reduction:
Blacklisting numerous unused kernel modules to reduce attack surface
Brute force protection by locking user accounts for 24 hours after 50 failed login attempts, hardened password encryption and password quality suggestions
Disable and mask a variety of services by default (including cups, geoclue, passim, and others)
Security ease-of-use:
Installing bubblejail for additional sandboxing tooling
Tooling for automatically setting up and enabling LUKS TPM2 integration for unlocking LUKS drives
Tooling for automatically setting up and enabling LUKS FIDO2 integration for unlocking LUKS drives
Toggles for a variety of the hardening set by default, for user convenience (ujust --choose)
It's the malware app. Typical Android malware like this asks for invasive permissions to then abuse them. Play Services doesn't provide apps permissions on their behalf.
iOS has per-image access permissions, #GrapheneOS has storage scopes. Please use these features. You shouldn't be saving copies of your seed phrase like this too.
nostr:nprofile1qqstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgspzpmhxue69uhkummnw3ezumt0d5hszrnhwden5te0dehhxtnvdakz7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcnv0md0 I tried to check if a user has internet permission enabled for my app but it always returns true even when disabled
Is this something GrapheneOS can fix or its something that should be fixed upstream?
That is intentionally done. We pretend the permission is granted but that the network is down. It prevents crashes and keeps app compatibility.
#GrapheneOS version 2025020500 released.
• full 2025-02-05 security patch level
• rebased onto AP4A.250205.002 Android Open Source Project release
• kernel (Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold): switch to Mali GPU kernel driver from Android 15 QPR2 Beta 3 to include additional security fixes
• Vanadium: update to version 133.0.6943.49.0
• GmsCompatConfig: update to version 154
We're in the news again
https://www.pcmag.com/news/google-fixes-android-bug-potentially-exploited-by-law-enforcement
Android security patch backports are available but not the AOSP / Stock Pixel OS update for this yet. Potentially the other Android releases are still vulnerable until the update arrives. Usual Android updates on their own don't fix this until the monthly patches come. In this case we were 1-2 months ahead.
https://grapheneos.org/features#more-complete-patching
We released a new update with the early backports (2025020300) as well.
nostr:nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43q4gnztg nostr:nprofile1qqstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgspzpmhxue69uhkummnw3ezumt0d5hszrnhwden5te0dehhxtnvdakz7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcnv0md0
🤔 A concern for GOS?
(removed previous post since got more info)
We had this patched early, appears likely around mid-December. We also have features like USB-C port control that makes exploiting the kernel USB drivers harder, that feature was actually meant for it.
We posted a thread earlier elsewhere about it, I just cross posted to Nostr now.
February 2025 Android Security Bulletin includes a heap buffer overflow in a Linux kernel USB peripheral driver (CVE-2024-53104) marked exploited in the wild. It's likely one of the USB bugs exploited by forensic data extraction tools. We block them using these.
https://source.android.com/docs/security/bulletin/2025-02-01
By default, #GrapheneOS blocks new USB connections when the device is locked in the Linux kernel and at a lower level via the USB-C and pogo pins controllers to defend the firmware and lower-level Linux kernel code too. Data is blocked in hardware once connections end.
https://grapheneos.org/features#usb-c-port-and-pogo-pins-control
If a user connected a malicious USB device while unlocked which tried to exploit this, general purpose exploit protections come into play. For the majority of the OS, our hardened_malloc project provides strong protections against heap corruption exploits. Kernel heap hardening is a separate thing.
One of the stronger defenses in hardened_malloc is our own implementation of hardware memory tagging (MTE) which integrated shortly after it shipped in production with the Pixel 8 and we had it enabled by default in around a month of release.
Linux kernel has a standard disabled by default implementation of hardware memory tagging. We very recently began enabling to defend it from issues like this USB heap corruption vulnerability. It's a major improvement but still not nearly as good as hardened_malloc.
We also already had CVE-2024-53104 patched prior to this month since we ship the kernel.org LTS revisions long before the Android Open Source Project / stock Pixel OS. Our systemic defenses are far more important because they work before vulnerabilities are known, so we didn't lead with that.
Many people have the misconception that security is about patching vulnerabilities. That's the bare minimum. Security should to be part of the design and implementation from the beginning. Linux kernel is an example where that wasn't the case at all and it's hard to provide it.
Linux kernel is a large monolithic kernel, meaning it has no internal isolation. All of the code including obscure drivers enabled in the build have access to everything it does. It's almost entirely written in C, a memory unsafe language where many tiny mistakes are code execution vulnerabilities.
Linux kernel is currently a major weak point for Android's security. It's the easiest way out of both the app sandbox and the more constrained sandboxes used for Android media processing and Chromium renderer processes. The Linux kernel is also a major physical and remote attack vector itself.
Android is moving towards writing new Linux kernel device drivers in Rust to prevent most of these vulnerabilities. We'll leave that to them and will be focusing on deploying better exploit protections and more heavily using hardware-based virtualization for better sandboxing than Linux can provide.
We haven't added these because they have issues with leaks. It doesn't block an app trying to do internet access through an indirect method