6 ms·

> 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'

> 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:\

ranger_danger 1y ago
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.
- yjftsjthsd-h 1y ago
  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.
- cakealert 1y ago
  > 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.
  - b112 1y ago
    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 1y ago
  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/ 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 1y ago
    > 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.
- ysnp 1y ago
  >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 1y ago
    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.
    - ysnp 1y ago
      >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.
      - yjftsjthsd-h 1y ago
        Yeah, I definitely think it's an excellent goal to erode the cases that need root. It is a powerful escape hatch, and I think it's important that it exist, but it's also a good thing to not need it. The difference is that I don't believe the system will ever cover everything I want to do, so I consider that escape hatch to be really important.
subscribed 1y ago
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.
- jampekka 1y ago
  If the risks are so immense, surely we shouldn't be allowed root on our laptops either?
  - bornfreddy 1y ago
    Pssst, quiet, don't give them any ideas... :-/
  - paulhart 1y ago
    That's a Chromebook, no?
    - jampekka 1y ago
      Chromebooks have Developer Mode that gives full root. https://www.chromium.org/chromium-os/developer-library/guides/device/developer-mode/ https://www.chromium.org/chromium-os/developer-library/guide...
  - ajjahs 1y ago
    [dead]
  - codethief 1y ago
    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.
crapple8430 1y ago
You can root GrapheneOS just fine. Moreover you can even re-lock the bootloader after rooting. See: github.com/chenxiaolong/avbroot
- tarruda 1y ago
  After unlocking and then re-locking, will the phone still pass all necessary attestations to be able to use things like Google wallet and banking apps?
  - chuckadams 1y ago
    Google Pay has never worked on GrapheneOS. GOS supports the attestation API -- a superset of it in fact -- but unless banking apps and Google Pay add GrapheneOS's keys specifically, they're not going to work, locked bootloader or no. (Google Wallet runs fine for storing cards and tickets and whatnot, you just can't pay with it)
    - strcat 1y ago
      Most banking apps don't disallow GrapheneOS. A growing subset are banning using any alternate OS including GrapheneOS, but there's also progress on convincing those apps to permit GrapheneOS via hardware attestation. Most banking apps do work.
    - sterlind 1y ago
      it'd be really nice to exert pressure on GPay or at least banking apps to add GOS's keys. accepting only Google's keys is anticompetitive.
      - strcat 1y ago
        Most banking apps permit GrapheneOS. We estimate around 10% ban it via the Play Integrity API, which is gradually increasing. The good news is that around a dozen banking apps have added explicit support for GrapheneOS. Swissquote recently implemented it via hardware attestation to check the GrapheneOS verified boot keys per https://grapheneos.org/articles/attestation-compatibility-guide https://grapheneos.org/articles/attestation-compatibility-gu....
charcircuit 1y ago
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.
- oneshtein 1y ago
  > 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 1y ago
    This kind of mentality is why malware became such a big issue on Windows. It turned out ignoring security and just relying on the user to not be stupid doesn't work. 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."
    - oneshtein 1y ago
      So, your proposition is to remove their ability to install antivirus software, like Google does in Android? Users know about this problem and know how to mitigate it. Get out of my way, please.
      - Scrubbed4426 1y ago
        No, the goal is to move to a system that doesn't rely on badness enumeration (antivirus) as a primary defense. You can rely on the app sandbox and the security model of the system to keep it in check. 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.

ranger_danger 1y ago

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.

yjftsjthsd-h 1y ago
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.
cakealert 1y ago
> 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.
- b112 1y ago
  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 1y ago
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/ 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 1y ago
  > 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.
ysnp 1y ago
>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 1y ago
  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.
  - ysnp 1y ago
    >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.
    - yjftsjthsd-h 1y ago
      Yeah, I definitely think it's an excellent goal to erode the cases that need root. It is a powerful escape hatch, and I think it's important that it exist, but it's also a good thing to not need it. The difference is that I don't believe the system will ever cover everything I want to do, so I consider that escape hatch to be really important.

subscribed 1y ago

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.

jampekka 1y ago
If the risks are so immense, surely we shouldn't be allowed root on our laptops either?
- bornfreddy 1y ago
  Pssst, quiet, don't give them any ideas... :-/
- paulhart 1y ago
  That's a Chromebook, no?
  - jampekka 1y ago
    Chromebooks have Developer Mode that gives full root. https://www.chromium.org/chromium-os/developer-library/guides/device/developer-mode/ https://www.chromium.org/chromium-os/developer-library/guide...
- ajjahs 1y ago
  [dead]
- codethief 1y ago
  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.

crapple8430 1y ago

You can root GrapheneOS just fine. Moreover you can even re-lock the bootloader after rooting. See: github.com/chenxiaolong/avbroot

tarruda 1y ago
After unlocking and then re-locking, will the phone still pass all necessary attestations to be able to use things like Google wallet and banking apps?
- chuckadams 1y ago
  Google Pay has never worked on GrapheneOS. GOS supports the attestation API -- a superset of it in fact -- but unless banking apps and Google Pay add GrapheneOS's keys specifically, they're not going to work, locked bootloader or no. (Google Wallet runs fine for storing cards and tickets and whatnot, you just can't pay with it)
  - strcat 1y ago
    Most banking apps don't disallow GrapheneOS. A growing subset are banning using any alternate OS including GrapheneOS, but there's also progress on convincing those apps to permit GrapheneOS via hardware attestation. Most banking apps do work.
  - sterlind 1y ago
    it'd be really nice to exert pressure on GPay or at least banking apps to add GOS's keys. accepting only Google's keys is anticompetitive.
    - strcat 1y ago
      Most banking apps permit GrapheneOS. We estimate around 10% ban it via the Play Integrity API, which is gradually increasing. The good news is that around a dozen banking apps have added explicit support for GrapheneOS. Swissquote recently implemented it via hardware attestation to check the GrapheneOS verified boot keys per https://grapheneos.org/articles/attestation-compatibility-guide https://grapheneos.org/articles/attestation-compatibility-gu....

charcircuit 1y ago

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.

oneshtein 1y ago
> 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 1y ago
  This kind of mentality is why malware became such a big issue on Windows. It turned out ignoring security and just relying on the user to not be stupid doesn't work. 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."
  - oneshtein 1y ago
    So, your proposition is to remove their ability to install antivirus software, like Google does in Android? Users know about this problem and know how to mitigate it. Get out of my way, please.
    - Scrubbed4426 1y ago
      No, the goal is to move to a system that doesn't rely on badness enumeration (antivirus) as a primary defense. You can rely on the app sandbox and the security model of the system to keep it in check. 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.