boldsuck GrapheneOS does not use Debian-based distributions and recommends against Debian-based distributions due to very poor security. That sentence has been removed from your post.

DeletedUser125

where even the simplest of tasks like toggling airplane mode can't be automated

This is not true.

This same "security" model that conveniently prevents us from unbloating regular android phones and control permissions.

Suggest you avoid derailing threads and making these kinds of attacks on our work. It is in fact a real and very important security model. It's unclear how it stops you from controlling permissions when that is part of what it enables unlike a system without that kind of app sandboxing. It also clearly doesn't stop you using a different OS.

missing-root That makes no practical difference since those provide the same functionality. Even if you entirely avoid all the ways of escalating privileges to root from there, your applications and data is in your main user where they largely run with full access as your user. Sandboxing is largely opt-in and has holes in the containment of apps. It's still designed around granting most access at install time based on whatever the app requests. Anything running as your main user is equivalent root if you ever escalate to root from it, but even if you don't it has access to everything that matters on a typical system without any exploitation involved.

The attack surface of sudo for privilege escalation from unprivileged users is present simply by having it installed as a setuid binary along with other setuid binaries. Any reasonably well contained applications can't make use of those due to having their ability to elevate privileges disabled. On a system that's using whole system MAC policies without huge holes in it, it would barely be relevant but it wouldn't be present on those systems in the first place in practice.

    This has all been very enlightening, so thank you all! I was trying to compare threat models as though both systems were designed with them in mind, but it sounds like the main point I was missing was "mainstream desktop OSes were NOT designed with a threat model in mind".

    For what it's worth, I'm not planning to root anytime soon. I do occasionally get fed up by the sandboxed file system (trying to move about in Termux but finding myself unable to access a decent chunk of the system), but I definitely get it more now. And I have to mirror @Xtreix 's thoughts: With stock OS, there was always a nagging sense in the back of my mind of how little control I had, but with (official, non-root) GrapheneOS, I feel much more in control and, even without sudo access, do feel like the proper owner of the device at long last. Which is why I'm willing and happy to trust the security experts here and do what they say.

    Suggest you avoid derailing threads and making these kinds of attacks on our work.

    For what it's worth, I don't think ekeere was criticizing the GrapheneOS security model in particular. It is definitely true that the Android security model (in the abstract) can and has been used for nefarious purposes to make it difficult to remove bloatware (I had a smartphone way back when that had an unremovable NFL app; the football app was apparently so integral to the system that I wasn't allowed to touch it). That's not your fault. That's good technology being used by bad actors to do bad things.

    And I do feel like that's relevant to what I was asking about. It's easy for a newbie like me to come in here, still riding my high from switching to Linux and expecting the same of GrapheneOS. It's easy for the Android security model to get a bad rep among power users when the average person's experience with it is "No, you can't uninstall or disable Alexa, she's too important".

      Mercerenies Termux has very poor support for Android APIs and modern Android. It could provide far better support for handling shared file access and many other things but doesn't. It was largely written in a way that the same thing could be done far better by simply running a virtual machine instead of trying to do things in the Android way and integrate well with the OS. There will be better support for running a foreign CLI environment via virtual machines built into the OS soon.

        GrapheneOS Oh? Is that a GrapheneOS-specific feature you're planning, or something coming to Android as a whole? If you have a link, I'd love to read more about what's planned.

          Mercerenies
          Google is doing a lot of work on AVF https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/Virtualization/README.md

          Within AOSP theres a new 'terminal' app which they are building which facilitates downloading debian and configuring a vm. Its included in the stock Pixel OS developer previews of android 15 QPR2 and android 16.

          GrapheneOS has various plans for utilizing VMs to run isolated processes to improve security in the OS and to enable running desktop operating systems, giving users ability to run desktop operating systems and their apps.

            GrapheneOS absolutely. Some of these issues are getting already fixed. run0 is not setuid so in theory you can remove the others.

            SELinux confined user accounts are being developee but not prioritized

              Carlos-Anso Within AOSP theres a new 'terminal' app which they are building which facilitates downloading debian

              How come Google went with Debian for the Linux environment in AOSP and also ChromeOS, when this distro has "very poor security"? I'm just curious, there must be a good reason for it. Or maybe not and it was just some Google engineer's personal preference.

                missing-root

                run0 is not setuid so in theory you can remove the others.

                This doesn't mean that what it does is better or more secure.

                SELinux confined user accounts are being developee but not prioritized

                SELinux is a policy framework. It's fairly meaningless to talk about it being used without specifics. It's hardly used at all in Fedora.

                  GrapheneOS in other words, keeping our devices safe requires multiple layers of security. There is no silver bullet.

                  Pretty sure Debian maintainers patch or investigate reports faster than MS or Google. Those 2 probably get hundreds or more reports per day from all over the world about any number of vulnerabilities but only a small fraction are reproducable and match the criteria those platforms pay out.

                  probably went off path a bit, my bad

                    Rooting is great if you know what you're doing or have a purpose to do it. It gives unfettered access to read and manipulate almost everything on the device. Which ends up being against the terms of the included licenses. So messing with files of any kind without exactly knowing what you are doing is absolutely designed to have consequences.

                    Like everything now a days, a multi layered approach to the security on your devices is your only viable option.. Which means accepting Google as the one true G

                      GrapheneOS

                      Yeah all user files are unconfined, which is being worked at, but still not really useful

                      Viewpoint0232 How come Google went with Debian for the Linux environment in AOSP and also ChromeOS, when this distro has "very poor security"?

                      Hard to know exactly how they arrived at the decision to use debian. They have done this as a tool to be used by software developers. I guess they decided that carefully using tools in the VM, when necessary, while leveraging the security of the host OS provides adequate security.

                      I am assuming they will keep the android implementation hidden away in Developer options.

                      GrapheneOS I am really grateful to the GrapheneOS team for what you do, GOS is the only OS for smartphones that provides real security. But I still have a question. Most arguments about root boil down to the fact that it breaks verified boot. But you can avoid this if you build GOS+Magisk yourself on a trusted device, for example, on a smartphone with GOS without root and sign with your own key. Tell me, please, in this case there will still be a significant degradation of security? If you grant root rights only to a few trusted applications and with verified boot

                        DeletedUser126
                        Hardly any system processes in AOSP get root. Increasing the number of things that can use root opens up security holes.

                        If security is a concern then root should not be used. Theres always another way to achieve what you want. If you cant just use an app to get the functionality you are looking for and you really need changes to system files you should make your own builds with the changes that you want rather than making changes using root.

                        Outside of development and reverse engineering/examining apps Ive yet to see any really compelling uses of root. Generally its people who have been rooting for years and got used to having a rooted device. Theres little to loose by letting go and a lot to gain.

                        • Edited

                        nullable Pretty sure Debian maintainers patch or investigate reports faster than MS or Google

                        No, Debian is anti-security and Microsoft and Google are doing much better, Google contributes a lot to hardening the Linux kernel, the .deb packages present in Debian-based distributions are riddled with vulnerabilities, many of which date back several decades. Debian is often used for the server side, because it's free and easy to use.

                        nullable Rooting is great if you know what you're doing or have a purpose to do it

                        No the rooting on phone is not great and there's always a better way.

                        nullable This is not how security patches work and that's definitely not the case.

                        nullable It greatly reduces the security of the OS by having it designed that way even if you never use it.

                        It gives unfettered access to read and manipulate almost everything on the device.

                        No, it doesn't. It gives immense access within the OS which is not full control over the device. It also doesn't mean you can persistently modify the OS unless you've removed additional security features beyond what you've already removed for that.