- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
After using LineageOS for long time, I have finally moved to GrapheneOS. I use a lot of banking and financial apps which I never felt comfortable using on LineageOS due to lack of proper sandboxing, unlocked bootloader etc.
GrapheneOS works flawlessly just like Android. You don’t even notice there’s hardening underneath. Also it protects from Google’s evil location tracking using WiFi/Bluetooth or even when the Location is turned off. I don’t understand how people in general are comfortable with Google tracking all the time. You can use Google Play and Play Services in a sandbox that works just like regular installation, but without deep tracking.
If you haven’t tried GrapheneOS, try it. You won’t go back to regular Android.
I would like to switch, but there are a couple of points that are still holding me back right now:
Charge limits, on LOS I can root the phone, install ACC and still use the OTA updates, if I apply the patch afterwards. (Will be resolved in A15)
Option for sandboxed MicroG, IMO privacy is also very important for security, and people should be able to decide if they like more privacy or more security.
Option for rooting sandboxed apps from outside. IMO I, and a person, like to have full control over my phone. Trust often comes with control. If I choose to trust one app to have root access to another app in order to inspect it, then this should be possible. Sandboxing could allow one app to have root access to individually chosen other apps, thus limiting the impact compared to system-wide root access. Maybe offer rooting gated behind a separate hardware token authentication. (sudo like) A lot there can be improved IMO, while still providing it and making it more secure in general.
I know that my understanding of security and privacy might be different from what GrapheneOS understands, but as a long time Linux Admin, I don’t like black boxes, I like to peek into them, modify or patch them, when they do something I don’t want them to do, etc. So that when I enter personal information into them, I am still in control what happens to them, at least that is my desire.
Taking control away from the user in order to “improve security” might be a valid approach to some, but it is not something I have much trust in.
What are you contemplating switching from? Does your current OS meet those criteria?
I am currently using a rooted LOS with MicroG. It certainly is not as secure as GrapheneOS in terms of app sandboxing, encryption, regular security updates, etc., but I have control of the system, in case I need it, for instance ACC, F-droid privilege extension (F-Droid auto updates), ReVanced Manager (not using it currently) etc.
I trust GrapheneOS much more than Apple, but both go into a similar direction with their understanding of security. IMO taking control away from the user might be a good option, if you are dealing with just regular consumers, but I don’t really like the “one-size-fits-all” approach of it. And it is my device, I should be allowed to decide what I want to do with it.
BTW, this is just a personal annoyance of mine. The GrapheneOS devs do a very good job.
You can root GOS like any other Android-based OS. It’s just highly discouraged, completely unsupported and, in the opinion of the GOS devs, you will no longer be considered to be running GOS since you are compromising the core OS by doing so.
Exactly right. However all the downsides you have when doing that sort of defeats the purpose. So a GrapheneOS native way to control your device would be nice.
I didn’t realize GrapheneOS limited control like that. Thanks for sharing!
Like others already said, you can still root your GrapheneOS, there are two ways to do this:
Just unlock your bootloader, flash Magisk or whatever, done. Disadvantages, you cannot lock your bootloader again, thus creating a huge security gap where an attacker, when gained physical access to your phone, overwrites your boot partition and you boot your compromised system without noticing. Which is bad, IMO.
Recompile GrapheneOS with Magisk installed, signed it with that key and use this key in your bootloader to lock it. You essentially created a GrapheneOS fork, can no longer use their OTA update server and use the security updates, etc. You need to create this yourself.
Yeah, they don’t prevent you from doing it, the same as original ROMs don’t prevent you from doing it.
As someone that moved to Linux and has become accustom to full control of my system, I finally feel seen when it comes to GrapheneOS. Here’s to a native root solution down the road, your take a la sandboxing sounds nifty.
They don’t.
Would you mind elaborating?
Sure, like I said above, GOS doesn’t at all prevent you from rooting the device. They only discourage it from a security point of view. Regarding MicroG, I’ve never had need for it myself but I’ve read many other posts over the years from users who have installed it on GOS in lieu of Graphene’s own implementation.
I would argue that overall GrapheneOS provides more control over the OS than some other Android-based operating systems.
Very interesting, thanks!
Maybe CalyxOS would be a better fit then?
What’s ACC? Anyway I would strongly discourage using root under Android as it breaks the security model. You should find ways around using root and if you can’t you probably shouldn’t be doing on your phone anyway. Root is very dangerous as it can survive a factory reset.
As for MicroG, it is sandboxed but it does require device admin for full functionality. It isn’t running as root but it requires a lot of device permissions. You can turn off the permissions you don’t need but that could break things.
ACC - Advanced Charging Controller, which allows to set charge limits, thus extending the battery life, which should have been part of Android from the beginning,
Security isn’t a binary, security works like an onion, you have multiple layers of security and multiple decisions to make on every level. Currently you might be right, that having root access to a device might compromise it in some ways, but that isn’t necessarily so and depends on how it is done.
This kind of thinking is the ‘I know better than you’ mentality, that I sometimes see around people advertising GrapheneOS. Having ‘root’ permissions to the device is owing it, I want to decide what to do with it, not the vendor of the ROM, or who ever else. They aren’t me, they don’t know what I want to do with it.
The goal of security models is allowing me, the owner, to do what ever I want with my device, while preventing others, non-owners, un-trusted applications or the internet from doing what they want with my device. If the security model doesn’t allow me, the owner, to do what I want, then it failed its job at least partially.
Why is that dangerous? The first thing I do, when I get a new phone is boot into the boot loader, and overwrite the whole partition, then the system is trusted again, at least if I trust the vendor of the boot loader. When I want to do a factory reset, I do the same, overwrite the flash with a fresh OS image.
IMO, there are other reasons why the current implementation of root are dangerous: They currently considered binary and I think they could be implemented more gradually. Like one application having root over individual other applications, e.g. accessing their files. Allowing/Disallowing individual privileged system calls, or access to specific system files, etc. All of this could be hidden behind a switch in the developers menu. Maybe only allow applications to gain root access when using a registered hardware token, etc.
In order for MicroG to work full, you need to fake the signature, which requires a patch to the system, or root privileges.
You can make changes to the OS when it isn’t booted. You can even compile your own image. The problem is having root in the application layer. You are exposing yourself to unnecessary risk. Ideally you should flash a overlay in the Lineage OS recovery or TWRP. You can do this for a few other things such as the F-droid privileged extension.