• General

  • Seeking Clarification on Potential Security Compromise of KernelSU

Respected GrapheneOS maintainers,

Greetings! I have been a long-time LineageOS user, relying on KernelSU for root access. Recently, I have been deeply impressed by GrapheneOS's philosophy toward security and privacy. However, I find myself conflicted, as my workflow currently depends on root privileges. Allow me to briefly explain my use case:

1.Managing Low-Quality Apps: Many apps developed by local software companies here are notoriously poorly engineered. They generate excessive amounts of useless files (cache, logs, residual data) within their private directories, often with no user-accessible cleanup mechanisms. To mitigate this, I routinely use open-source tools like Material Files to manually inspect and delete these files — a process requiring root access to bypass app sandboxing.
2.Other Tools: Certain tools I rely on, such as VPN Hotspot, require root access to function properly.

I have carefully read your explanations (e.g., the December 9, 2022 posts) about how root access fundamentally undermines the OS security model. Your arguments are both clear and compelling. That said, I wish to seek clarification regarding KernelSU, a newer root implementation that claims to address some of Magisk’s shortcomings. To my understanding:

KernelSU operates at the kernel level without spawning privileged userland daemons (unlike Magisk).
It enforces strict scoping: Its "app profiles" feature allows granular restriction of granted privileges, and apps receive only the permissions explicitly granted via its "app profiles". This eliminates the risk of unsafe or vulnerable apps making broader changes to the system. Also, It avoids modifying userland/system app behavior unless explicitly specified.

While I fully acknowledge that such modifications would forfeit community support (and I have no intention of burdening the team with related issues), I wish to respectfully ask: From a purely technical security/privacy perspective, does KernelSU’s design meaningfully mitigate the risks described in your earlier critiques?

Additionally, if you are willing to address them, I have two technical questions:

AVB & Boot Flow: If I install KernelSU via its default method (injecting an LKM into the ramdisk) and sign the OS with my own keys using tools like avbroot, would GrapheneOS boot successfully? If so, could I enroll my custom key into the device and relock the bootloader?
Custom Builds: If the above is infeasible, would compiling a custom GrapheneOS build be necessary? Beyond merging KernelSU’s kernel patches, are there additional steps required to ensure compatibility?

I sincerely appreciate your time and expertise in considering this inquiry. The transparency and rigor of your project continue to inspire admiration. I look forward to your guidance on these matters.

Best regards,
lingyicute

    lingyicute From a purely technical security/privacy perspective, does KernelSU’s design meaningfully mitigate the risks described in your earlier critiques?

    The whole point of root is to have absolute total access to everything, while the whole point of Android/GrapheneOS is to contain access and give you revocable permissions (you can't revoke root access from a bad app because granting it root access is equivalent to turning it into a rootkit with all the consequences of that). Furthermore, Android/GrapheneOS have verified boot which means changes to the OS are done at the OS source level and supplied as OTA updates, and rebooting the device loads a clean known valid OS, and making changes to the OS at runtime using root access is inherently incompatible with the idea of removing runtime-made changes and booting a clean known valid OS using verified boot.

    So regardless of implementation, root is inherently incompatible with Android/GrapheneOS security.

    Also, modifying the kernel to provide that stuff doesn't sound very secure to me.

    EDIT: Also to answer your question, it's certainly possible that having root access has valid uses to it. It's not secure, but it could definitely be useful. Ideally everything needed to be done by it would be available to do in a standard way without root so root wouldn't be needed. Have you tried the "Clear cache" button for these badly coded apps you use?

        lingyicute You need to consider two things:

        One: rooting your phone regardless of method increases attack surface. Any app can potentially make use of it.

        Two: You can't exclude that the root app which potentially is "safe" today, wont be compromised tomorrow, popping your phone open.

        Long story short, and imo rooting android today is not worth the hassle. I used to run custom kernels with root and shit for a very long time because I 'needed' it, eventually decided it's not worth the hassle and potential issues it brings. If it would be better isolated, then maybe.

            0xsigsev If it would be better isolated

            The whole point of root access is to have zero isolation

                Watermelon Hi~
                Traditional root implementations indeed grant apps unrestricted capabilities, which is why many security-focused systems, like GrapheneOS, strongly discourage root. However, KernelSU offers a different approach with its app profile functionality.

                With app profiles, KernelSU allows for granular permission management. Each app granted root privileges can have its access tightly controlled through predefined profiles, effectively limiting its actions to those explicitly allowed. This means that, rather than giving an app complete, unrestricted control, KernelSU provides a way to confine root privileges to well-defined boundaries.

                While I understand the concerns about root inherently undermining security, I believe that KernelSU’s design mitigates these risks by enforcing strict scoping policies. This approach does not entirely align with the traditional “root equals absolute control” notion, and I find that to be an important distinction. Of course, this remains a debated topic in security circles, but I feel it is a meaningful step toward balancing flexibility and security.

                    Watermelon Yeah, the isolation here means it is similar to *nix where you have separate user to run root stuff.

                    Hence I said with the current (potentially forever the same) implementation it's not worth it.

                      lingyicute That depends then on which controls it gives you, and regardless, bypassing any of the containment/sandboxing on GrapheneOS is a security downgrade.

                      The point is that you're either trying to access things that you aren't given access to normally, which means you want to bypass the sandbox, or that you want to make runtime changes to the OS, which means you want to bypass verified boot. On that note, it'd be stupid to lock your bootloader because you'd only restrict yourself while not actually restricting a potential attacker because you'd still not have verified boot as it's fundamentally incompatible with having root access.

                          Watermelon you'd still not have verified boot as it's fundamentally incompatible with having root access.

                          KernelSU’s design ensures that it does not modify system files but instead injects its kernel module into the boot image. Theoretically, this approach should not interfere with Verified Boot mechanisms, as Verified Boot can still validate the integrity of the boot chain against the originally signed state. Common security concerns typically arise from modifications to the system partition or OS binaries, which would violate Verified Boot’s guarantees. KernelSU sidesteps such issues by dynamically loading its module at runtime, avoiding persistent changes to critical partitions. Thus, it should technically coexist with Verified Boot.

                          That said, strict security philosophies prioritizing "untouched" systems might argue that even adding a kernel module deviates from the "clean" state endorsed by OEMs, potentially introducing attack surface. However, from an engineering perspective, KernelSU’s implementation may minimizes risk compared to traditional root methods that alter system partitions.

                              lingyicute You misunderstood me. I wasn't speaking about how KernelSU works, I was speaking about what you'd be using it for: Either to

                              1. Bypass the sandbox, or
                              2. Bypass verified boot.

                              Either of this is a security downgrade from what Android/GrapheneOS provides you.

                                  Watermelon I see. I understand these reduce security, but I’m conflicted about the extent to which it does so and whether the trade-off is worth the risk. By the way, when I try to bypass sandbox restrictions—for example, accessing an app’s private data directory—should this be categorized as "my file manager (e.g., Material Files) bypassing the sandbox"? If such a file manager has been thoroughly audited, could it be considered free of security risks? (Of course, KernelSU itself might pose security risks. However, the kernel technologies it employs, such as namespaces, have existed for years and stood the test of time. The likelihood of inherent security flaws seems low in my opinion.)

                                      lingyicute KernelSU operates at the kernel level without spawning privileged userland daemons (unlike Magisk).

                                      That sounds like an attractive target for malware!

                                      lingyicute If I install KernelSU via its default method (injecting an LKM into the ramdisk) and sign the OS with my own keys using tools like avbroot, would GrapheneOS boot successfully?

                                      If avbroot handles dm-verity, maybe. Otherwise, I suspect not. And of course there might be other issues.

                                      Overall there isn't that much support on this forum for advising people on how to "mod" GrapheneOS, especially not undermining the security model. Obviously nothing stops you, but the topic might best be handled elsewhere, e.g., XDA.

                                          lingyicute By the way, when I try to bypass sandbox restrictions—for example, accessing an app’s private data directory—should this be categorized as "my file manager (e.g., Material Files) bypassing the sandbox"?

                                          I wouldn't be quick to say it's your file manager bypassing the sandbox, but it's certainly a sandbox bypass. I don't know exactly what extra code is ran with what privileges when you do it and it might technically include, as a side effect, any app granted accessibility permission or other dangerous permissions.

                                          lingyicute If such a file manager has been thoroughly audited, could it be considered free of security risks?

                                          No. Root is a risk. Audits aren't guaranteed to find all issues.

                                          lingyicute I understand these reduce security, but I’m conflicted about the extent to which it does so and whether the trade-off is worth the risk.

                                          lingyicute The likelihood of inherent security flaws seems low in my opinion.

                                          I wouldn't trust KernelSU to be secure, although admittedly I haven't really researched this project and the people that develop it. I do trust GrapheneOS and the official GrapheneOS wouldn't provide security features like sandboxing and verified boot just to supply another feature that bypasses them, even if only partially. At the end I'm not denying that sometimes root can be useful, but it's never secure and hopefully the usefulness is decreased over time by functionality and APIs getting extended/restricted (more restrictive APIs could still bring you more functionality because they could give you more control, restricting apps from behaving badly/uncleanly) in new Android/GrapheneOS versions.

                                          You mentioned that you want to clear private folders of apps. Have you tried the "Clear cache" button in the app list in the Settings app? Also if they save it in the external "Android" folder in the shared storage then you can access it without root on the latest stable GrapheneOS.

                                          VPN on hotspot users is something I've heard the project officials saying they won't implement because it breaks the isolation between your device's traffic and the hotspot users' traffic. Can't you just use a VPN on the client devices?

                                                    Watermelon Have you tried the "Clear cache" button in the app list in the Settings app?

                                                    The "Clear cache" button doesn't work at all because the companies designing those apps never considered user experience in the first place.

                                                    Watermelon GrapheneOS wouldn't provide security features like sandboxing and verified boot just to supply another feature that bypasses them, even if only partially.

                                                    This has always confused me. Security features like sandboxing and verified boot are clearly meant to defend against malware/attacks, not restrict users. Yet the current implementation feels confused - for instance, AOSP has never granted users access to app-private storage by default, which should morality belong to the device owner. However, This could easily be implemented safely using existing patterns. As I understand it, newer Android versions block apps with storage permissions from accessing the external "Android" folder, yet allow user access it through DocumentUI. The same logic could extend to app-private storage: grant DocumentUI access and let users manage app-private storage through that framework.

                                                    While AOSP's stance is understandable (aligning with Google's philosophy of "aggressively defensive security" towards the end consumer - much like how ChromiumOS, built on Linux, strips users of the freedom to natively execute binaries — however this actually forcing them to rely on tools like chromebrew, which function similarly to Android rootkits in unavoidably expanding the attack surface.), I've always hoped custom ROMs might implement this (although I've never mentioned this idea of mine to anyone until today (◍•ᴗ•◍) ). However, on second thought, they may lack motivation since their users usually root the device anyway. But GrapheneOS users can't have both root and security. Why doesn't GrapheneOS officially implement such user freedom-enhancing features? An official implementation could actually preserve the OS's security achievements while empowering users.

                                                    Watermelon more restrictive APIs could still bring you more functionality because they could give you more control, restricting apps from behaving badly/uncleanly

                                                    Unfortunately, API changes will never include "restricting apps from dumping junk files in private storage."

                                                    Watermelon VPN on hotspot users is something I've heard the project officials saying they won't implement because it breaks the isolation between your device's traffic and the hotspot users' traffic. Can't you just use a VPN on the client devices?

                                                    Ahahaha, I get it. I use hotspot with VPN because I like to collect old Android devices, like Samsung Note 4, and do some research. And running a VPN program on them takes up too much performance.

                                                    (On a side note) Maybe the only solution is to find and set a secondary device with LineageOS + KernelSU for running unscrupulous apps or VPN Hotspot?

                                                              lingyicute useless files

                                                              Why do you wanna clean these useless files? Are you short of storage space?

                                                              lingyicute VPN Hotspot

                                                              This is impossible without root. I would recommend you to use PC to create a VPN hotspot if feasible.

                                                                  lingyicute

                                                                  1.Managing Low-Quality Apps

                                                                  Modify the APK for the apps to have debugging enabled and you can access the files via ADB.

                                                                  2.Other Tools: Certain tools I rely on, such as VPN Hotspot, require root access to function properly.

                                                                  These aren't proper implementations of the features and some of those including VPN hotspot are largely misguided and not actually a good approach to use. Why do you need to route traffic from the hotspot via the Owner user VPN?

                                                                  It enforces strict scoping: Its "app profiles" feature allows granular restriction of granted privileges, and apps receive only the permissions explicitly granted via its "app profiles". This eliminates the risk of unsafe or vulnerable apps making broader changes to the system. Also, It avoids modifying userland/system app behavior unless explicitly specified.

                                                                  This still greatly reduces security in multiple ways. Even not granting access to anything is still reducing security.

                                                                  AVB & Boot Flow: If I install KernelSU via its default method (injecting an LKM into the ramdisk) and sign the OS with my own keys using tools like avbroot, would GrapheneOS boot successfully? If so, could I enroll my custom key into the device and relock the bootloader?

                                                                  This is not going to work with our kernels. You would have to build the OS with the changes. Far better to build the OS with the added features you want without this.

                                                                    lingyicute This has always confused me. Security features like sandboxing and verified boot are clearly meant to defend against malware/attacks, not restrict users. Yet the current implementation feels confused - for instance, AOSP has never granted users access to app-private storage by default, which should morality belong to the device owner. However, This could easily be implemented safely using existing patterns. As I understand it, newer Android versions block apps with storage permissions from accessing the external "Android" folder, yet allow user access it through DocumentUI. The same logic could extend to app-private storage: grant DocumentUI access and let users manage app-private storage through that framework.

                                                                    While AOSP's stance is understandable (aligning with Google's philosophy of "aggressively defensive security" towards the end consumer - much like how ChromiumOS, built on Linux, strips users of the freedom to natively execute binaries — however this actually forcing them to rely on tools like chromebrew, which function similarly to Android rootkits in unavoidably expanding the attack surface.), I've always hoped custom ROMs might implement this (although I've never mentioned this idea of mine to anyone until today (◍•ᴗ•◍) ). However, on second thought, they may lack motivation since their users usually root the device anyway. But GrapheneOS users can't have both root and security. Why doesn't GrapheneOS officially implement such user freedom-enhancing features? An official implementation could actually preserve the OS's security achievements while empowering users.

                                                                    You can try to open a feature request for it on GitHub:
                                                                    https://github.com/GrapheneOS/os-issue-tracker/issues
                                                                    Try to present your viewpoint on it including these thoughts and maybe you'd be convincing enough? It's worth a try. (For your info: If they tag your issue as "priority-none", it just means they aren't prioritizing your feature request — if they look at your issue and keep it open rather than closing it, it means they think there's merit/sense in what you're requesting. "priority-none" doesn't mean they're opposed to ever doing it.)

                                                                    lingyicute (On a side note) Maybe the only solution is to find and set a secondary device with LineageOS + KernelSU for running unscrupulous apps or VPN Hotspot?

                                                                    That could be a fine choice.
                                                                    EDIT: How about writing a letter to the developers of the bad apps? (If you do, write a letter for each developer separately, don't write one mail and sent to all of them together, that could be flagged as spam.) Or call their customer service if you can? Pressure them to get their stuff fixed rather than you having to go buy another (insecure) phone for their stupid apps.