lingyicute

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.)

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.

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.

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