I am trying to use HTTP Toolkit to inspect the HTTP requests apps make, however it is not working because root access isn't allowed via ADB.

With a USB connection, none of the following commands return 'root':
adb shell, then su -c whoami
adb shell, then su root whoami
adb root, then adb shell, then whoami

What do I need to do to enable root access over ADB?

You will need to root your phone, which is possible with magisk but it will result in a non-safe phone with open bootloader.

Rooting a device makes big holes in the security architecture of Android. The operating system has been designed severely limit processes with root.
If you want to inspect html traffic there are safe ways to do so.
eg. check out https://github.com/emanuele-f/PCAPdroid

If you really need/want root its possible to make a userdebug build of the OS (see the build instructions on the website) but its not recommended for a 'production' (one you are going to use) device

a year later

I'm trying to better understand the exact vulnerabilities (and potential future mitigations) presented by rooting.

In an older GOS Reddit post, the GrapheneOS mod wrote:

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.

Do I understand correctly that this means that a "UI" way of granting root (such as an interactable Magisk app) is the big "UI layer" vulnerability, whereas requiring that root access can only be granted over ADB would close the vulnerability?

    hemlockiv Do I understand correctly that this means that a "UI" way of granting root (such as an interactable Magisk app) is the big "UI layer" vulnerability, whereas requiring that root access can only be granted over ADB would close the vulnerability?

    If the system is set up so that, on a day-to-day basis, there is a program designed to grant root access to pluggable modules, unless that program and all of the pluggable modules are genuinely very secure (this is unlikely) then the system is at substantial risk.

    If while a developer is debugging an app, the system has a mode where the developer can inspect and modify system state that is normally carefully protected, that's not such a big deal, especially since it is expected that the developer is debugging using a dedicated target device which does not contain private data, banking credentials, etc., all of which are presumed to be on the developer's daily-driver device instead.

    Overall, rooting is about expediently brushing aside the system's integrity mechanisms, instead of carefully developing an app that lives within the security model and has only the privileges it actually needs. People may choose to turn off large hunks of the security system on a daily-use device containing private information, but that dramatically reduces the integrity of the system.

    Both developer options and userdebug builds are designed for developers to use on development devices while developing. That is the safe way to use them.

      de0u nless that program and all of the pluggable modules are genuinely very secure (this is unlikely)

      Why is that very unlikely? Apps are sandboxed by default on Android, so unless the app has a serious design flaw, I'm not following how there would be a substantial risk from a non-rooted app hijacking a rooted one.

      hemlockiv An accessibility service trivially has root access. A keyboard can probably get root access, and so on.

      Going back to the original quote, I could understand how an Accessibility Service or a keyboard app could more easily hijack something like the Magisk app, because those are examples of things that could automatically send input too fast for the user to notice/prevent. (I'm not sure what "so on" could refer to, as accessibility services, keyboards, and apps with the "display over other apps" permission granted are the only things I can think of that can send arbitrary input to the UI).

      In that case, I don't see how ADB is actually much more secure, given that (as already referenced in the quote) you can now use Wireless ADB to create on-device ADB shells. The good news is, this actually seems relatively straightforward to lock down?

      1. The hacky solution: Via some system module, only allow Magisk to be accessed when all non-system Accessibility services are disabled, all "display over other apps" permissions are temporarily revoked, and only the system GOS keyboard is active.
      2. The proper solution: Prevent services and apps from overlaying or interacting with Magisk in the same way that the system prevents overlays/interactions with Keyguard.

      de0u Overall, rooting is about expediently brushing aside the system's integrity mechanisms, instead of carefully developing an app that lives within the security model and has only the privileges it actually needs. People may choose to turn off large hunks of the security system on a daily-use device containing private information, but that dramatically reduces the integrity of the system.

      yes yes we are all in agreement that Magisk is the root of all evil, su is antithetical to security, and "rooted GrapheneOS" violates US trademark law. I'm asking because I am just trying to better understand the technical aspects of the security issues surrounding the su problem.

        hemlockiv yes yes we are all in agreement that Magisk is the root of all evil, su is antithetical to security, and "rooted GrapheneOS" violates US trademark law. I'm asking because I am just trying to better understand the technical aspects of the security issues surrounding the su problem.

        I suspect the "sarcastic Magisk support forum" might be xdaforums.com rather than here.

          de0u I suspect the "sarcastic Magisk support forum" might be xdaforums.com rather than here.

          I suspect you're right. Thankfully, that's not what either of us are here for. As previously stated, I'm trying to understand software securities, specifically the ones mentioned by a GrapheneOS mod. If you want to engage in that conversation, I would welcome your insights. I don't think either of us particularly benefit from condescending diatribes on responsible cellphone stewardship.

          hemlockiv I'm not following how there would be a substantial risk from a non-rooted app hijacking a rooted one

          And you will personally audit the code of each app, line by line?

          hemlockiv In that case, I don't see how ADB is actually much more secure, given that (as already referenced in the quote) you can now use Wireless ADB to create on-device ADB shells.

          You still need to toggle it in the developer menu, and authorize the fingerprint of the debugger.
          This is part of the OS and not some shady module that can be bypassed.

          You can have an Android device with root, adb, all permissions granted, bypass certificate pinning, etc.
          But that will be considered a lab device, not something you want on a production (personal) daily phone.
          So the entire "root" concept defeats GOS purposes on many levels.
          You can still build your own -userdebug variant with su, but then some apps won't work on such builds.

            23Sha-ger You still need to toggle it in the developer menu, and authorize the fingerprint of the debugger.
            This is part of the OS and not some shady module that can be bypassed.

            I am still looking for a clear answer of what the actual threat is. If I am understanding the OP correctly then the risk is primarily from accessibility, overlays, or keyboards sending UI input to a privileged app (this is in fact the only question I asked in my first comment, and the only one nobody is apparently confident enough to answer). In that scenario, adb isn't inherently safer, because the existence of any on-device ADB shell (e.g. aShell, LADB, Tasker, ShizuTools) presupposes that it has been authorized as a debugger; the risk is that malicious apps could send input to that debugger.

            If this understanding is incorrect, please correct me! But either way, please stop defaulting to condescension. Everyone in this thread is a Graphene user, and no one has actually suggested rooting it. I am trying to understand the nature of security risks. You can't fight a threat if you don't understand it. Please stop treating the desire for knowledge like a sin by itself.

            10 days later

            Alright, I've done some reading on the 3-letter forum and I think the answer to my original question is that I AM misunderstanding the whole thing.

            It looks like Magisk (as in, specifically Magisk, not necessarily "root" in general like you could get with a debug build) requires granting root privileges to the entire "System.UI" app. This now makes sense why the GOS mod said that any app like a keyboard that can send commands to SystemUI could trivially achieve root.

            Why Magisk requires this is beyond me, though. I think I might ask about it on r/Magisk.