Introduction to GrapheneOS
68 comments
·September 10, 2025electric_muse
codethief
> The user containers are very helpful
You mean different user accounts? Those are available on stock Android, too.
subscribed
On GrapheneOS they're profiles. Pretty much the same as with the stock aosp, but they add very extensive support - like notifications forwarding and a perfect balance between security and convenience, 2FA with shorter pin.
a0sud0a8s
True, although on GrapheneOS, apps on different profiles can remain active when you switch and notifications can be sent to the primary profile if you choose.
ysnp
I think it depends on the Android distribution. I am not sure it is available on Samsung's One UI.
gertop
Multiple user is available on Samsung. Both multiple profiles as well as work profile.
Samsung also has "secure folder" which isolates apps and files and presumably uses multiple users to do the isolation.
dosshell
> I have to have TikTok for work
I'm sorry but what? Your job demands what apps you have installed on your PRIVATE phone!?
TranquilMarmot
I would assume for advertising/business account. There are things you can only do on the TikTok app that you can't do on the web.
tietjens
Sincere question: what is the point of using this OS for privacy and then using Google services? The intro runs though how it’s very easy to do this. Maybe I’m missing something.
cool_cherry
It's actually really great!
Google Play Services is a dependency for some apps, and GrapheneOS allows for people to take steps to protect their privacy while still being able to use those apps.
First, with GrapheneOS google play services run in a sandbox like any other app. (play services have more privileged access in vanilla android)
It also works well with a multi-user setup. The default account in Android is the "owner account" and in GrapheneOS (and AOSP) you can use the owner account to create multiple distinct user accounts on the device. Then, you can only install google play services in one user account. Google play services won't start if you're not logged into that user account.
Google play services won't have visibility into your other user accounts and what you're doing there. And even in your account with play services installed, there's a bit more privacy because of the sandboxing (although I believe google play will know all of the apps installed in that user account)
There's a full explanation here: https://grapheneos.org/usage#sandboxed-google-play
Edit: I am a web security researcher and longtime user of GrapheneOS and have always been impressed by the features, frequent security updates, and focus on usability, security, and privacy. They've upstreamed numerous security improvements to Android and other open source projects (so if you're running Android, they've probably made your phone more secure!).
https://grapheneos.org/faq#upstream
I encourage folks to join me in making a regular small donation to the project if you have some cash to spare. They're doing good work.
ysnp
GrapheneOS primarily exists to give you tools to exert more control over what apps have access to and to better protect your data. What you do with those tools is entirely your own concern. Where those apps come from is not GrapheneOS's concern.
I don't think most people use Google services out of choice anyway, but more because sometimes that's the only way to get functionality you may need.
krior
Afaik, Google services are run in a sandbox on Graphene OS.
tietjens
Hm ok but location data etc still goes to them? What about the device fingerprint?
I’m just wondering what the selling point for using Graphene with Google is. Very Graphene curious.
thothless
as a new graphene adopter, still figuring stuff out myself, but it's been surprisingly easy and satisfying to do a hard cut-over to graphene.
cool_cherry explained exactly how I've been using it, with my main 'owner' account not having play services installed at all, only instead installed on another user, which only takes a few seconds to switch to.
you can easily install owner apps onto other user profiles. or grant/forbid the other user profiles to install apps themselves.
users are not tied to google accounts, only your google play installations.
I was able to install google play apps on 'owner' user and then uninstalled google play services and play store. if they don't require play services to function, they work fine, otherwise they just might not function or may function/look surprisingly differently when they don't have their network connections.
location, network, other permission have defaults and can set them on per-app basis like on normal android.
a unique device MAC address is generated for each wifi connection.
arminiusreturns
Security, including privacy, is about layers of hardening. In this case, minimization of leakage and other privacy concerns for some can still be worth the tradeoffs. For example, some apps literally refuse to work on a completely de-googled phone. (I ran one for many years with no google services). Also, the general control the user gets offers a lot more ability to harden than most android. I bricked my phone and am currently borrowing one and using stock android and there are things like facebook that are literally uninstallable... At least on lineage/graphene the user can actually control the system.
yjftsjthsd-h
> GOS does not allow you to become root on your phone though, it just gives you more control through permissions and profiles.
It really is sad that there isn't any ROM with Graphene's permission and sandboxing features while still leaving the user in control. IIRC it's theoretically possible since they publish the code, but one assumes it would be a non-trivial effort:\
crapple8430
You can root GrapheneOS just fine. Moreover you can even re-lock the bootloader after rooting.
See: github.com/chenxiaolong/avbroot
ranger_danger
If you have the UI layer able to grant root access, it has root access itself and is not sandboxed. If the UI layer can grant it, an attacker gaining slight control over it has root access. An accessibility service trivially has root access. A keyboard can probably get root access, and so on. Instead of a tiny little portion of the OS having root access, a massive portion of it does.
In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
cakealert
> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed.
The same is true even of an operating system such as QubesOS. And it's a minimal risk.
Not providing optional root access on GOS makes it only useful if you have a constrained application in mind for the phone. I don't have time to compile GOS with root so I just use LineageOS instead.
bbarnett
It's useful for general use just fine.
But you could always do both. Compile it, but preinstall a specific set of apps as root, no su.
yjftsjthsd-h
EDIT: This is a reply to the 2nd(?) version of your comment before it was silently changed into something different.
Yes, I'm sure it is. But I don't consider that a tolerable tradeoff, and I believe we could have a system that has most of the best of both worlds.
ysnp
>This is not what people are referring to when they talk about rooting on Android
Would this have been easier or more possible if Android had a full capability-based security model?
yjftsjthsd-h
Arguably Android has a capability-based security model, though it suffers from being ... well, it's not what you'd build if you were doing it from scratch today. Hindsight is 20/20. But I'd tentatively say not really, because the point of root is to get outside the existing capabilities. As an example: For a while, the most common root app I ran was one to limit charging to 80% or whatever to make the battery age more gracefully.[0] The whole reason that needed root is because there wasn't a capability/permission for that; the app couldn't ask the OS to let it control charging, because nobody even thought to expose that API surface.
[0] This was later obsoleted by the OS adding that feature natively, which is an interesting angle to consider; directly supporting the things people root for definitely helps, but you're unlikely to ever get everything so it's not a panacea.
yjftsjthsd-h
Quoting inline since parent has been rewritten multiple times now...
> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed. If the UI layer can grant it, an attacker gaining slight control over it has root access. An accessibility service trivially has root access. A keyboard can probably get root access, and so on. Instead of a tiny little portion of the OS having root access, a massive portion of it does.
Android has an established way to handle permission dialogs that require the user to confirm their approval, including use of fingerprint/PIN/password to authenticate. If it's good enough to unlock and decrypt the device, it's good enough to control root access. Besides which, I think
> An accessibility service trivially has root access.
is hitting https://xkcd.com/1200/ ; an a11y service already has access to everything inside the sandbox (including all your sensitive data), and the system settings that control permissions and sandboxing.
> In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
I'm tentatively willing to agree, but I don't see the point? 1. If an attacker controls persistent state, don't they already control all the other permissions, including what security domains exist and what permissions are given to apps. 2. You don't have to persist it; even just one-off root access is quite useful.
> A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
Agreed, that's not what I want.
ranger_danger
> Android has an established way to handle permission dialogs that require the user to confirm their approval
With the advent of choicejacking I don't think I want to trust permission dialogs anymore.
> including use of fingerprint/PIN/password to authenticate
IMO if you have the UI layer able to grant root access at all, even with requiring re-authentication, it still already has root access itself and is therefore not sandboxed.
charcircuit
Giving the user control does not mean giving the user root. Giving root breaks Android security model. Whatever capability you want should be implemented as a proper feature to avoid breaking the security of the device.
Equating control to root is an outdated way of thinking that comes from a time before the principle of least privilege existed. The way UNIX did things should not be put on a pedestal.
treyd
That would be nice, but trying to get those kinds of functionality upstreamed into GOS so they can be exposed tovapps in a structured way with the usual permissions model is a high effort.
There needs to be some escape hatch that you can use, even if your grandma doesn't have access to it.
charcircuit
There doesn't need to be an easy escape hatch. The escape hatch is to wipe and flash a fork.
oneshtein
> Giving root breaks Android security model.
It's true only if user is the threat for the user, e.g. a user with low IQ but high curiosity, but such user usually cannot install GrapheneOS.
charcircuit
This kind of mentality is why malware became such a big issue on Windows. That mistake shouldn't be made again and there is no reason to artificially restrict the audience of an OS to people who don't have "low IQ."
subscribed
Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.
I dint understand why you insist on this massive risk to be laid on on everyone.
GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
yjftsjthsd-h
> Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.
> GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
It really sounds like you call it very easy, then promptly turn around and say that it's not easy but that's okay because it should be hard. You're also conflating the ability to assess security risks with the ability to build Android from source and modify it in the process, even though these skills are mostly unrelated.
> I dint understand why you insist on this massive risk to be laid on on everyone.
Largely, I don't agree that it's a "massive risk" in the first place. I don't believe that user-controlled root access is a problem, and I certainly don't believe that a default-off option to enable root access constitutes a problem.
subscribed
No, it is very easy.
You either build a debug image, so you just have it, or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it.
Use your own keys to sign and you're golden.
The assumption is you know what you're doing, and then it's very easy. If you don't, then you likely shouldn't.
I am not really "conflating" these in a way you suggest: it's not just about building the image but deeper understanding that will bring both.
It's not disconnected from the project, but it's inherently within the project. SURE you can consider these two separate skills, but within the context of "getting the root on the GOS build" it's one. If you don't know how to make it happen, you don't have a skill to safely use it.
And lastly, it's okay if you don't consider it a massive risk. I do.
Now let's consider the risks of that, - https://cybernews.com/security/rooted-android-ios-devices-su... - https://www.talsec.app/blog/what-is-rooting-and-how-to-prote...
For you it's not a risk, okay, I guess. I mean, if you're a security researcher with a considerable reputation, you can certainly argue with authority, but I don't see the angle.
You argue from the position of convenience and capabilities. Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.
jampekka
If the risks are so immense, surely we shouldn't be allowed root on our laptops either?
subscribed
And there's reason why normal windows / Linux laptops are less secure.
Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it?
And that's even without having access to root (imagine if someone had written a malware like Heartbleed or Shellshock, which then could quietly persist, patch your firmware, or actually do anything it wants?)
I hope you're at least running your laptop with selinux in enforcing mode :)
codethief
From a security point of view that would be a good idea, or at least making sure you don't need root for everyday tasks. Requiring root to, e.g., install & configure applications is a huge antipattern IMO.
bornfreddy
Pssst, quiet, don't give them any ideas... :-/
paulhart
That's a Chromebook, no?
ajjahs
[dead]
sfdlkj3jk342a
They actually do include how to do it in their official build guide. Just change the build target from -user to -userdebug. All other steps remain the same. That will give you adb root access.
yjftsjthsd-h
> That will give you adb root access.
I don't want adb root access? I want to be able to run apps with root access.
fsflover
> massive risk
Are you saying that the Qubes OS security model is worse than the GrapheneOS one?
subscribed
Non sequitur?
GOS is not running a flavour of mainline Linux, but Android. They're nevertheless planning on moving to virtualisation as well https://discuss.grapheneos.org/d/24154-grapheneoss-roadmap-r...
For now it's as good as it gets.
IlikeKitties
It's a different approach to compartmentalization and the security risk of root in Grapheneos is different to that in QubesOS. But you know this looking at your bio, you just chose to ignore it.
junkblocker
There did not seem to be an RCS story. Whether the device is RCS capable or not seems to be up to some unfathomable Google logic the tickling of which didn't work for me. Having old RCS chat histories and new RCS chats not work made me go back to stock quick.
throawayonthe
you need the google messaging app for RCS
ThePowerOfFuet
RCS is an abomination.
NoiseBert69
Bought an Google Pixel Tablet only for GOS. Installation worked like a charm and all my applications are still working without problems.
Loving it.
TranquilMarmot
Installing it on a tablet is a good idea. I hesitate to install it on my phone because I'm concerned about a few things I rely on not working (RCS, tap to pay, nearby devices to unlock rental cars)
fsflover
GrapheneOS developers keep insisting [0] that their security model is the only reasonably secure approach in the world, despite that Qubes OS proved that wrong.
ysnp
>their security model is the only reasonably secure approach in the world
They have not said anything like that. In fact there are plenty of things about the current GrapheneOS + Pixel end result that they would change if they had the resources and support to do so. They have repeatedly praised or highlighted improvements in iOS and other less mainstream operating systems.
QubesOS is a completely different project with different goals and constraints. GrapheneOS have praised the isolation model of Qubes repeatedly, but have always said it is a strong approximation of many laptops. Older laptop operating systems (Windows/macOS/desktop Linux distros) do not aim to provide similar protections against threats that the newer mobile operating systems have done.
ranger_danger
How did Qubes OS prove them wrong? You still have root on qubes, humans still make errors, IMO it's therefore technically still less secure. Of course this assumes your goal is to prevent bad things from happening in general, regardless of how it happens, and not just say "yea the OS is secure but humans can still mess things up by using it wrong".
I think protecting people from themselves is a noble goal that is often overlooked, even if many will disagree with me.
IlikeKitties
What utter nonesense. Just because the GrapheneOS Team doesn't do free work to support devices you like doesn't mean they prevent you from doing it. It's still 100% opensource and you are free to port it yourself to whatever device you please. The entitlement of people that want the grapheneos project to work for them for free is insane. Fucking hire a dev to work on this for a few month yourself if you don't like the device support.
ajjahs
[dead]
I just bought a pixel from best buy to install gos, which was an ordeal.
At checkout they looked at me like I was up to no good when I said I didn’t want to give them my name, address, and phone number just to purchase the device. I didn’t set up a plan. They said it was for “restocking” or something.
Fortunately they accepted obviously fake info. These front line sales people just don’t care as long as they can say they followed the policy.
The user containers are very helpful. I have to have TikTok for work and I put it in a container all by itself with a vpn on kill switch. And for one app that needs google play services, I have it a container with that.
The duress passcode is super clever, too. You enter a different device passcode and it just wipes the device.