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:\
See: github.com/chenxiaolong/avbroot
(Google Wallet runs fine for storing cards and tickets and whatnot, you just can't pay with it)
Google will not using their service for tap-to-pay.
I'm okay with losing access to Google wallet while using Graphene os (I can just use plain old credit cards), but I would like to have the option to revert it in the future.
Myself I have not reverse engineered the Titan M2 security chip, but surely it uses eFuse or OTP memory for anti rollback protection mechanisms and such.
These are really basic hardware security primitives. I'm curious why you're under the impression Pixels wouldn't use eFuse.
The Pixel 6 is only mentioned in regards to anti-rollback protection. This has nothing to do with unlocking and later relocking the bootloader. Pixels have always supported relocking the bootloader with a custom root of trust, i.e. custom AVB signing keys used by a custom, user-installed operating system.
https://source.android.com/docs/security/features/verifiedbo...
> The Xbox 360, Nintendo Switch, Pixel 6 and Samsung Galaxy S22 are known for using eFuses this way.[8]
Anti-rollback protection is a security feature, eFuses are hardware primitives that can be used to implement it. Bootloader locking is another security feature that can be implemented with eFuses.
If you have any data denying the use of eFuses in the Pixel 6, please share it, that is what I was interested in this sub-thread. I really did not understand the relevance and the correctness of your comment.
I thought you claimed that Pixels also used eFuses to disable certain features after unlocking the bootloder once, like Samsung devices do. That's why I pointed out that Pixel devices have always had support for relocking the bootloader with a custom root of trust.
Your response to this comment https://news.ycombinator.com/item?id=45244933 made it seem that way, because you appeared to disagree that "Pixel devices don't have anything like the Samsung Knox eFuse, which blows after running a third-party bootloader".
I guess that was a misunderstanding.
On Samsung devices, blowing the Knox eFuse permanently disables features tied to Knox (e.g. Samsung Pay, Secure Folder). ("can never go back to a state where it passes all checks")
Pixels do not have an equivalent eFuse that permanently disables features (discounting the ability to flash previous versions of Android). Restoring stock firmware and relocking the bootloader will give you a normal Pixel.
Indeed it may be true today that "restoring stock firmware and relocking the bootloader will give you a normal Pixel", I completely understand what you mean.
But that is NOT the same thing as "Pixels do not have eFuses to flag devices that have been modified before". Please share data supporting this claim if you have it.
It is possible that existing Pixels have such eFuses that internally flag your device (perhaps bubbling up to the Google Play Integrity APIs) but they don't kill device features per Google's good will.
My question is 100% about the hardware inside the Titan M2 and how it is used by Google. I don't think the answer is public, and anyone who has reverse engineered it to such detail won't share the answer either.
There's no such thing for Pixels, and it also doesn't void the manufacturer warranty.
I don't know if there's any good solution to this, since all this seems to be necessary for the security model.
EDIT: Wait, isn't this what A/B partitions are for? (ie, you can brick one partition and still boot from the other) Also, shouldn't it be possible to flash an image signed with the correct keys without unlocking the bootloader and wiping the user data?
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.
https://www.chromium.org/chromium-os/developer-library/guide...
So if I don't use sudo then the problem with root is solved?
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 :)
The availability of application sandboxen and the availability of root access are two entirely separate security concerns.
If the GUI stack is vulnerable, then those sandboxes could be broken out of. The idea behind not allowing an app to access root is to remove the attack surface introduced by the GUI stack. An alternative interface to a GUI would be some physical connection (like usb-c). So accessing root exclusively via a console port or USB would be safer in theory.
This is true regardless if it's a phone or a PC.
Desktops are unfortunately waaaay behind something like GrapheneOS or iOS in terms of sandboxing. The closest in the desktop world is Qubes OS, but that's not a realistic alternative to normal OSes for the common user.
I very much don't want to have some external device to have root access to my computer.
If iOS type sandboxing where I can't access most of the data at all is ahead, I'm glad to be behind.
I don't want adb root access? I want to be able to run apps with root access.
Are you saying that the Qubes OS security model is worse than the GrapheneOS one?
By the way, personal attacks are against the HN Guidelines.
GrapheneOS is designed so you don’t need root to run apps or manage the device. Compartmentalization is on an per app level. And you already know how qubes does compartmentalisation.
This sounds like a great news to me, thank you.
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.
Do you have any statistics to show about how secure a micro-kernel is? I can't believe it can be better than this: https://www.qubes-os.org/security/qsb/
An attacker can do cross-guest exploits via the network too, which would not be considered within the scope of that list. As an example, if an attacker could exploit the network VM via a Linux kernel TCP/IP vulnerability, then exploit connected virtual machines from there with the same vulnerability. Network driver vulnerabilities are another way to get that initial foothold. It wouldn't be a hole in the architecture implemented by QubesOS but it would still give them control over everything that matters 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.
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.
It is my understanding that that only gives root to adb, not apps, so no.
> or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it.
If we're at the point of patching source trees, then no, we've left the realm of "very easy" behind. Installing Magisk is easy. Building Android from source, let alone patching it, is not.
> 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.
I really disagree. Knowing when to click the allow button or not is a separate skill from building/patching a ROM from source.
> 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...
I'd love to, but you'll have to mention what they might be. Both of those links treat root as nearly synonymous with compromise but never bother to explain how that compromise would occur, just 1. root 2. ??? 3. malware. That's fear-mongering, not a threat model.
> 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.
Or, we could avoid Appeal to Authority and talk threat models. The only one I've seen yet in this thread is people claiming that malware can fake out permission dialogs and that this is a problem for root permissions but somehow leaves the rest of Android's permission model in a usable state, which is... an interesting claim.
> Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.
Many people making vague claims might technically be a "consensus" but it's not actually meaningful. If you've got an actual threat model, let's hear it, otherwise there's not much point to this.
You are moving from a small handful of processes that get root access and are heavily constrained by selinux policies and are nowhere near userspace to putting root access behind a weak UI prompt. That is the ability to modify the system at runtime. If the system can be modified and the bar to that modification is trivially bypass-able, privilege escalation becomes monumentally easier for an attacker. Because the system can be modified *it cannot be trusted*.
Here is a recent report of widespread advanced malware looking to see if a device is rooted - https://www.lookout.com/threat-intelligence/article/badbazaa...
Here is a report of malware using root - https://zimperium.com/blog/new-advanced-android-malware-posi...
Root does not only provide privilege escalation, it also provides attractive options for exploit persistence on a device, something which is difficult to achieve on modern Android and iOS.
Okay? I do actually think that should be blocked (good root is invisible), but I'm not seeing a problem.
> Here is a report of malware using root
To quote the article:
> In addition to collecting the messages using the Accessibility Services, if root access is available, the spyware steals the WhatsApp database files by copying them from WhatsApp’s private storage.
Note that it already uses a11y features to do the same thing regardless, but also this is another case of conveniently skipping all the important details. Seriously - "if root access is available, the spyware steals" - how did it get root access? If the "vulnerability" is that the malware asks the user for root access and the user gives it, that is not a vulnerability. A system where malware needs permission to do bad things is perfectly fine.
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.
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.
Users know about this problem and know how to mitigate it. Get out of my way, please.
Antivirus scanners are essentially useless on modern mobile OSes because they are limited to accessing the same things a malicious app or file would be.
No, I cannot rely on the app sandbox. If someone else controls a device, then this device can be used against me.
Your antivirus, scanner or not, is useless on your device for you.
My antivirus on my device is useful for me. It works fine on GrapheneOS (Pixel 6), but banned by Google on Pixel 5, which is not supported by Google with security updates. WTF?
Also no matter how technical you are, it's almost impossible for you to detect zero-click 0days for which you are more vulnerable to than people without root privileges. You running rooted OS actually become easier and less costly target than people without rooted OS.
I doubt that user-controlled root access is a significant variable in the face of zero-days; LineageOS+Magisk is more likely to resist attack than vendor ROMs that are lagging security updates by months.
Providing app-accessible root compromises the security of the OS even for people not using it since it provides root access to a substantial portion of the OS and provides a way to maintain persistent root access for an attacker. A quick tapjacking vulnerability exploit is all that's required to gain full control over the device with no way to detect or eliminate it. The attacker has root so they control all the user interfaces, etc. and can hide it. They can hide what happened and block an attempt at revoking it. The idea that it only impacts people negatively if they use it poorly is wrong. Using it at all is using it poorly anyway, since the right way to implement anything is not giving root access to an application. App-accessible root access is used as an insecure shortcut to implement features without proper security models where components are given the privileges they need to function and are split up to reduce attack surface.
For example, in Android, there's an isolated netd process with CAP_NET_ADMIN for configuring the network but it can't load eBPF programs itself, only bpfloader which it only does via predefined programs. This avoids a compromise of netd being able to compromise the kernel via eBPF. Similarly, a VPN service app providing features like local filtering and/or an actual VPN does not have CAP_NET_ADMIN or other highly privileged access. User interfaces in the OS configuring firewall functionality and other network configuration do it via netd. A common use of app-accessible root is giving root access to a GUI application to manage firewall rules directly rather than having a tiny privileged component doing it and then the GUI only being given the privilege of configuring rules through that in a structured way. Principle of least privilege, isolation, etc. are basic security concepts violated by this whole approach.
Giving the user root access is not the same as giving apps root access. The user having a root access shell is not nearly as harmful as having apps able to request it.
Apps can and will coerce users into doing things they shouldn't. Root access is inherently not required by someone like a firewall configuration GUI and not the right way for the implementation to be made. That's an example of an insecure implementation leading people to believe it requires giving broad root access to the OS and the app when it's not needed by a well written implementation. It's similar to apps demanding a permission like Contacts and refusing to work without it despite it not being required, which is why GrapheneOS provides Contact Scopes and similar features for overruling the demands from the apps. App accessible root access goes against the Android and GrapheneOS privacy and security approach to an extreme.
Nubia was hacked remotely. It received no updates for years, so it was an easy target. I unlocked Nubia and plan to install LineAge OS to it when my Pixel 5 will die.
Pixel 5 was hacked from close distance via WiFi or BT.
Pixel 6 with Graphene is not hacked yet.
Lack of root doesn't protect me.
However, I use SafeDot to monitor phone access to microphone, camera, GPS, so I'm alerted when it starts to beep, which creates problems for spies, so SafeDot is banned by Google at request of СІА. I cannot fix this, because Google controls my phone instead of me. SafeDot still works on Pixel6 GrapheneOS with warning notification about it «unsafety» though.
There needs to be some escape hatch that you can use, even if your grandma doesn't have access to it.
The point is that you should always be some supported workflow instead of the user having to go out of their way and modifying the base system.
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.
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.
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.
But you could always do both. Compile it, but preinstall a specific set of apps as root, no su.
> 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.
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.
So you're using a version of Android patched to remove all permissions? After all, in your threat model all apps can get permission to use the microphone and camera, make phone calls, access fine-grained location information, read and write files at will, etc. Frankly, I'm not sure what they'd get out of root at this point.
> 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.
Likewise, surely this applies to any permission system, and every other permission. The system UI controls every other permission in the system; if we assume it compromised, then everything else is already lost.
A permission that allows them to hide that they have access to everything, including other apps' data?
Would this have been easier or more possible if Android had a full capability-based security model?
[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.
For what it's worth, my understanding is that this has always been the position of GrapheneOS too. Given the resources and enough benefit/cost to allocate, the project would rather integrate or implement usability features at the OS level instead of encouraging people to expose attack surface. Specifically because GrapheneOS is a project meant to be primed to defend some of the most intimate and personal aspects of a person's life.