5 ms·

The grapheneos devs are really, really against root. What are your thoughts on that?

commoner 2y ago
Anyone who prefers root access on Android with a locked bootloader (on the OSes that support it) can use avbroot: https://github.com/chenxiaolong/avbroot https://github.com/chenxiaolong/avbroot Works great with CalyxOS and GrapheneOS.
- sureglymop 2y ago
  What about OTA updates? Do they preserve it?
  - strcat 2y ago
    No, it's not compatible with receiving official over-the-air updates. Similarly to if you build and signed the OS properly, you'll need to make each of the updates yourself. Unlike building and signing the OS properly, you will not have the basic security model intact but rather will be massively rolling back security and trusting a huge portion of the OS with root access. Giving root to a massive portion of the OS destroys the fine grained access control and isolation model used throughout the OS. It makes exploitation much easier to do and much easier to hide. It also makes persistence a given since persistent root access can be given out which means an attacker doesn't need any verified boot bypass anymore. It's odd to go through all this effort to continue signing the OS for verified boot while losing the main verified boot security model which makes it useful. If you want root access, build and sign userdebug builds with ro.adb.secure=1, which is officially supported by GrapheneOS and only exposes root access via ADB which you should only use from the computer where you're building the OS. It would be possible to add some kind of key combination at boot to disable loading user installed applications, etc. and instead making a terminal with root access available. Not clear how that's really useful though. Instead, what these projects are doing is giving out root access to a massive portion of the OS in order to be able to give out full root access to apps. This is used as a shortcut to implement features in a way that massively reduces security even if you never use it. Implementing those features properly integrated into the OS following the principle of least privilege is the proper approach. Most of the features people believe they need this hack to achieve are doable without it, such as filtering traffic with your own firewall rules while also using a VPN which is a standard Android feature available to apps.
  - commoner 2y ago
    No, over-the-air updates are not supported. The instructions for flashing updates patched with avbroot are here: https://github.com/chenxiaolong/avbroot?tab=readme-ov-file#updates https://github.com/chenxiaolong/avbroot?tab=readme-ov-file#u...
- strcat 2y ago
  This doesn't work with GrapheneOS but rather you can create a derivative of GrapheneOS without the core security model intact. Instead of a tiny core portion of the OS being trusted with root access, a massive portion of the OS is trusted with that. It's much easier for an application to compromise the OS. An attacker doesn't need exploits for privileged persistent compromise anymore but rather that's a given since the verified boot security model is no longer intact. The purpose of locking the bootloader is enabling verified boot, which is no longer intact with this approach. CalyxOS doesn't have a complete verified boot implementation for the OS like GrapheneOS and rolls back the standard security model a fair bit, but doing this rolls it back far more. You cannot have your cake and eat it too in this case. If you want modifications to the OS, you should use the official build instructions and avoid replacing the core of the OS with a rootkit trusting a massive portion of the OS to give out root access and trusting persistent state with root access.
  - deleted 2y ago
    [deleted]
  - commoner 2y ago
    avbroot is not officially supported by CalyxOS or GrapheneOS, but it does work with both OSes. The point of avbroot is to make root access available to trusted Android apps while leaving commands such as "fastboot flash" and "fastboot erase" disabled. There will always be a subset of users who prioritize functionality over security. This includes anyone who would root an Android device (and anyone who would use a desktop computer running most distributions of Linux, macOS, or Windows). I'll be glad to reconsider using root on Android if all of the functions of App Manager's "block trackers" feature[1] and Basic Call Recorder[2] were available on Android without root. [1] App Manager: https://github.com/MuntashirAkon/AppManager https://github.com/MuntashirAkon/AppManager [2] BCR (Basic Call Recorder): https://github.com/chenxiaolong/BCR https://github.com/chenxiaolong/BCR
NotPractical 2y ago
Not OP, but I think that their concerns are legitimate for the most part. One example they've brought up is that, with root, a single bug in the display server could lead to complete and immediate compromise of the entire device (assuming root access is gated by UI prompts as is common on most rooted ROMs). Additionally, with verified boot, persistent changes to the OS made via root would cause the phone to be unable to reboot, which limits what you can do with root (assuming you still want verified boot). GrapheneOS standards are much higher than on desktop Linux, where root can be acquired as easily as injecting a fake `sudo` into ~/.bashrc. Basically the idea is that there should be no need for root if everything is nicely gated by permission controls and high-level APIs. If every component of Android were actually well-designed, this idea would have more merit, but unfortunately there are still a few big gaps in what you can do with a rooted versus non-rooted device, e.g. custom firewall rules (which could provide a hotfix for the issue at hand here). When asked to expose more fine-grained firewall control to the end user, the Graphene devs basically responded that it's extremely difficult to set up firewall rules properly such that leaks are impossible [1], which may be true, but I'd like to think it's better than nothing. Also, because root access would break Android's protection against end user application tampering, that would likely rule out the possibility of GrapheneOS receiving special support from banking apps, which is something they hope to see in the future [2]. Anyway, this particular issue is definitely a bug in AOSP, and will hopefully be resolved promptly. It's being tracked here: https://issuetracker.google.com/issues/337961996 https://issuetracker.google.com/issues/337961996 [1] https://discuss.grapheneos.org/d/4113/6 https://discuss.grapheneos.org/d/4113/6 [2] https://grapheneos.org/articles/attestation-compatibility-guide https://grapheneos.org/articles/attestation-compatibility-gu...
- strcat 2y ago
  It's app accessible root with a massive portion of the OS trusted with giving out access to it that's a huge problem and massively rolls back OS security against compromise. It also means an accessibility service can trivially escalate to root with no way to revoke it beyond reinstalling the OS or doing a wipe from recovery. You also lose the main security properties of verified boot, which is based around avoiding trust in persistent state. Raising the bar for physical attacks is a secondary purpose of verified boot, not the main one. GrapheneOS already has fine-grained firewall support exposed to the user via the standard VPN service feature which despite misconceptions can be used while also using an actual VPN and there are multiple apps supporting this. It's not simply difficult to set up firewall rules where leaks aren't possible but rather it doesn't really work because not everything is done via direct socket access from the apps. This is why we have our Network toggle in the first place, which does a lot more than blocking direct socket access both to block indirect access and preserve compatibility by pretending the network is down for the most important APIs. These DNS leak issues which were reported to us earlier may be an app bug which can be worked around by the app. The OS could be changed to prevent this happening but that doesn't imply that it's an OS bug. More investigation is required to determine the cause and solution. We're also aware of a local network multicast leak that's not covered in Mullvad's post, which is very likely to be an Android OS bug but we aren't certain about that yet either. It's worth noting that neither the DNS leak issues or local network multicast leak issue impact the built-in VPN support. They're only happening with VPN apps. It's likely that some of this is caused by bugs in the Android VPN service app support (particularly the multicast packet leaks) but the DNS leaks are quite possibly an app flaw. Mullvad's post acknowledges they found a way to address one of the forms of leaks with changes to their app, which may be possible for the rest since there aren't leaks when the VPN is down but rather when it's in the process of reconnecting. It looks a lot like a race condition where the VPN is being activated before everything is in place, which could be a bug in the OS but could also be a bug in the app where it's doing something in a different order than what's intended.
strcat 2y ago
Making userdebug builds with ro.adb.secure=1 to have root access via ADB with the rest of the security model intact is officially supported by GrapheneOS. Using Magisk massively rolls back the OS security model and is strongly discouraged. Using ADB on a production device isn't recommended with or without root, but it's officially supported if you want to do it. If you only grant ADB access to the computer you use for building and signing the OS, it's not a big deal. You need to be aware that you need to heavily secure that computer and shouldn't use it for anything else though.
- switch007 2y ago
  Always appreciate your detailed replies here. Thanks!

Anyone who prefers root access on Android with a locked bootloader (on the OSes that support it) can use avbroot: https://github.com/chenxiaolong/avbroot https://github.com/chenxiaolong/avbroot Works great with CalyxOS and GrapheneOS.

sureglymop 2y ago
What about OTA updates? Do they preserve it?
- strcat 2y ago
  No, it's not compatible with receiving official over-the-air updates. Similarly to if you build and signed the OS properly, you'll need to make each of the updates yourself. Unlike building and signing the OS properly, you will not have the basic security model intact but rather will be massively rolling back security and trusting a huge portion of the OS with root access. Giving root to a massive portion of the OS destroys the fine grained access control and isolation model used throughout the OS. It makes exploitation much easier to do and much easier to hide. It also makes persistence a given since persistent root access can be given out which means an attacker doesn't need any verified boot bypass anymore. It's odd to go through all this effort to continue signing the OS for verified boot while losing the main verified boot security model which makes it useful. If you want root access, build and sign userdebug builds with ro.adb.secure=1, which is officially supported by GrapheneOS and only exposes root access via ADB which you should only use from the computer where you're building the OS. It would be possible to add some kind of key combination at boot to disable loading user installed applications, etc. and instead making a terminal with root access available. Not clear how that's really useful though. Instead, what these projects are doing is giving out root access to a massive portion of the OS in order to be able to give out full root access to apps. This is used as a shortcut to implement features in a way that massively reduces security even if you never use it. Implementing those features properly integrated into the OS following the principle of least privilege is the proper approach. Most of the features people believe they need this hack to achieve are doable without it, such as filtering traffic with your own firewall rules while also using a VPN which is a standard Android feature available to apps.
- commoner 2y ago
  No, over-the-air updates are not supported. The instructions for flashing updates patched with avbroot are here: https://github.com/chenxiaolong/avbroot?tab=readme-ov-file#updates https://github.com/chenxiaolong/avbroot?tab=readme-ov-file#u...
strcat 2y ago
This doesn't work with GrapheneOS but rather you can create a derivative of GrapheneOS without the core security model intact. Instead of a tiny core portion of the OS being trusted with root access, a massive portion of the OS is trusted with that. It's much easier for an application to compromise the OS. An attacker doesn't need exploits for privileged persistent compromise anymore but rather that's a given since the verified boot security model is no longer intact. The purpose of locking the bootloader is enabling verified boot, which is no longer intact with this approach. CalyxOS doesn't have a complete verified boot implementation for the OS like GrapheneOS and rolls back the standard security model a fair bit, but doing this rolls it back far more. You cannot have your cake and eat it too in this case. If you want modifications to the OS, you should use the official build instructions and avoid replacing the core of the OS with a rootkit trusting a massive portion of the OS to give out root access and trusting persistent state with root access.
- deleted 2y ago
  [deleted]
- commoner 2y ago
  avbroot is not officially supported by CalyxOS or GrapheneOS, but it does work with both OSes. The point of avbroot is to make root access available to trusted Android apps while leaving commands such as "fastboot flash" and "fastboot erase" disabled. There will always be a subset of users who prioritize functionality over security. This includes anyone who would root an Android device (and anyone who would use a desktop computer running most distributions of Linux, macOS, or Windows). I'll be glad to reconsider using root on Android if all of the functions of App Manager's "block trackers" feature[1] and Basic Call Recorder[2] were available on Android without root. [1] App Manager: https://github.com/MuntashirAkon/AppManager https://github.com/MuntashirAkon/AppManager [2] BCR (Basic Call Recorder): https://github.com/chenxiaolong/BCR https://github.com/chenxiaolong/BCR

NotPractical 2y ago

Not OP, but I think that their concerns are legitimate for the most part. One example they've brought up is that, with root, a single bug in the display server could lead to complete and immediate compromise of the entire device (assuming root access is gated by UI prompts as is common on most rooted ROMs). Additionally, with verified boot, persistent changes to the OS made via root would cause the phone to be unable to reboot, which limits what you can do with root (assuming you still want verified boot). GrapheneOS standards are much higher than on desktop Linux, where root can be acquired as easily as injecting a fake `sudo` into ~/.bashrc. Basically the idea is that there should be no need for root if everything is nicely gated by permission controls and high-level APIs. If every component of Android were actually well-designed, this idea would have more merit, but unfortunately there are still a few big gaps in what you can do with a rooted versus non-rooted device, e.g. custom firewall rules (which could provide a hotfix for the issue at hand here). When asked to expose more fine-grained firewall control to the end user, the Graphene devs basically responded that it's extremely difficult to set up firewall rules properly such that leaks are impossible [1], which may be true, but I'd like to think it's better than nothing. Also, because root access would break Android's protection against end user application tampering, that would likely rule out the possibility of GrapheneOS receiving special support from banking apps, which is something they hope to see in the future [2]. Anyway, this particular issue is definitely a bug in AOSP, and will hopefully be resolved promptly. It's being tracked here: https://issuetracker.google.com/issues/337961996 https://issuetracker.google.com/issues/337961996 [1] https://discuss.grapheneos.org/d/4113/6 https://discuss.grapheneos.org/d/4113/6 [2] https://grapheneos.org/articles/attestation-compatibility-guide https://grapheneos.org/articles/attestation-compatibility-gu...

strcat 2y ago
It's app accessible root with a massive portion of the OS trusted with giving out access to it that's a huge problem and massively rolls back OS security against compromise. It also means an accessibility service can trivially escalate to root with no way to revoke it beyond reinstalling the OS or doing a wipe from recovery. You also lose the main security properties of verified boot, which is based around avoiding trust in persistent state. Raising the bar for physical attacks is a secondary purpose of verified boot, not the main one. GrapheneOS already has fine-grained firewall support exposed to the user via the standard VPN service feature which despite misconceptions can be used while also using an actual VPN and there are multiple apps supporting this. It's not simply difficult to set up firewall rules where leaks aren't possible but rather it doesn't really work because not everything is done via direct socket access from the apps. This is why we have our Network toggle in the first place, which does a lot more than blocking direct socket access both to block indirect access and preserve compatibility by pretending the network is down for the most important APIs. These DNS leak issues which were reported to us earlier may be an app bug which can be worked around by the app. The OS could be changed to prevent this happening but that doesn't imply that it's an OS bug. More investigation is required to determine the cause and solution. We're also aware of a local network multicast leak that's not covered in Mullvad's post, which is very likely to be an Android OS bug but we aren't certain about that yet either. It's worth noting that neither the DNS leak issues or local network multicast leak issue impact the built-in VPN support. They're only happening with VPN apps. It's likely that some of this is caused by bugs in the Android VPN service app support (particularly the multicast packet leaks) but the DNS leaks are quite possibly an app flaw. Mullvad's post acknowledges they found a way to address one of the forms of leaks with changes to their app, which may be possible for the rest since there aren't leaks when the VPN is down but rather when it's in the process of reconnecting. It looks a lot like a race condition where the VPN is being activated before everything is in place, which could be a bug in the OS but could also be a bug in the app where it's doing something in a different order than what's intended.

strcat 2y ago

Making userdebug builds with ro.adb.secure=1 to have root access via ADB with the rest of the security model intact is officially supported by GrapheneOS. Using Magisk massively rolls back the OS security model and is strongly discouraged. Using ADB on a production device isn't recommended with or without root, but it's officially supported if you want to do it. If you only grant ADB access to the computer you use for building and signing the OS, it's not a big deal. You need to be aware that you need to heavily secure that computer and shouldn't use it for anything else though.

switch007 2y ago
Always appreciate your detailed replies here. Thanks!