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.
Seeking Clarification on Potential Security Compromise of KernelSU
- Edited
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.
- Edited
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
- Bypass the sandbox, or
- 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.
- Edited
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?
- Edited
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?
- Edited
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.
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.
- Edited
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.