Security Issues with Rooting GrapheneOS

MiniSota

I know GrapheneOS doesn't provide any support with rooting and strongly discourages it. However, what are the specific issues if you only grant root to trusted and vetted apps like Magisk, AFwall+, and Neo Backup? Obviously the security of the device will be much lower than a stock GrapheneOS device, but can it be worth the privacy and customization benefits?

Also, does preserving AVB using avbroot help with any of these security issues?

I appreciate any insights from individuals with more knowledge on this!

de0u

MiniSota In what sense are Magisk and the various plugins "vetted"?

First search result for magisk vulnerability: https://github.com/canyie/MagiskEoP

MiniSota Obviously the security of the device will be much lower than a stock GrapheneOS device, but can it be worth the privacy and customization benefits?

It depends. If after reviewing Magisk vulnerabilities the threat landscape they pose seems fine...

GrapheneOS

MiniSota The software you're listing is insecure and substantially reduce the security of the OS. You should use RethinkDNS and Seedvault which are secure and implemented through the officially supported mechanisms. Fully unconstrained root access shouldn't be used to implement something like a firewall as it's completely unnecessary and not a correct design. Giving unconstrained root access to a huge portion of the OS including the application layer and third party apps is an incredibly insecure and improper approach. It's being used as a shortcut to make it easier to implement despite awful security. A reasonable approach would follow the principle of least privilege, which is what's done for the OS functionality.

Also, does preserving AVB using avbroot help with any of these security issues?

You still get most of the major security downsides of giving root access to a huge portion of the OS and third party apps. You still lose many of the security properties of verified boot, but keep the physical anti-tampering aspect of it despite losing a lot of the anti-malware-persistence aspect of it.

MiniSota

GrapheneOS
Thank you for the helpful reply! One other question, does root on Linux, Windows, and macOS have similar security issues to a rooted Android? Or are is it less of an issue on those platforms because the OS is designed around the assumption that the user has root privileges?

GrapheneOS

There are much more detailed answers from us in previous threads about the same topic. Please read those first.

neotux

MiniSota

On Linux, running the whole system as root is an extremely bad idea. You will expose it to catastrophic risks from accidental mistakes, security breaches, and total system compromise.

That is why sudo (doas, run0) exists. You gain root access for a limited time to perform some system operation.

raccoondad

MiniSota does root on Linux, Windows, and macOS have similar security issues

Yes

yore

MiniSota Desktop operating systems were developed during a time where security was a lower priority, and as such were not made with security in mind. While they did eventually separate root from the unprivileged user, gaining root is much easier than smartphone OSes and root itself still has almost full access to the system.

Smartphone OSes on the other hand are built with the principle of least privilege. Standard Android devices run a few processes as root and even those are strongly enforced with SELinux, with no process running as unrestricted root. So when you root your device, you're essentially trusting your entire device even if there is any malware, giving extremely high privileges to an attacker and breaking verified boot / anti-malware persistence.

GrapheneOS

MiniSota It's a much bigger issue on those platforms but those also have atrocious privacy and security for their overall approach to applications. They're not designed to be private or secure operating systems. macOS has been successfully making a lot of progress to changing this, but there's very little progress for desktop Linux and Windows which are falling further behind on privacy and security.

GrapheneOS

neotux

On Linux, running the whole system as root is an extremely bad idea. You will expose it to catastrophic risks from accidental mistakes, security breaches, and total system compromise.

What you're describing applies to using it without root too. They do not have basic application sandboxing and very little sandboxing used throughout the OS.

That is why sudo (doas, run0) exists. You gain root access for a limited time to perform some system operation.

If you use these, your non-root user is equivalent to root in practice and you're also giving it to applications due to the lack of proper application sandboxing. Those tools do not address this at all. There's nearly no difference between root and a user with root access through those tools, which also means applications have it due to not being sandboxed and simply running as the user with all the privileges of the user in the general case.

neotux

GrapheneOS

GrapheneOS That is why sudo (doas, run0) exists. You gain root access for a limited time to perform some system operation.

If you use these, your non-root user is equivalent to root in practice and you're also giving it to applications due to the lack of proper application sandboxing. Those tools do not address this at all. There's nearly no difference between root and a user with root access through those tools, which also means applications have it due to not being sandboxed and simply running as the user with all the privileges of the user in the general case.

Maybe I was not clear in my wording. It wasn't meant to say to run any applications with sudo (etc.) but to perform some system maintenance like updating, installing packages, editing some config files and similar.

I don't know any other way of doing this in Linux than elevating the normal user to root temporarily and back to normal when the job is done.

GrouchyGrape

neotux this still doesn't solve all the issues mentioned, but you could use a user account that simply doesn't have root access. If something requires elevation (e.g. updates), you log out, log into an elevated account, then log out/back in to your unprivileged account.

This is general best practice of least privilege.

neotux

GrouchyGrape you could use a user account that simply doesn't have root access. If something requires elevation (e.g. updates), you log out, log into an elevated account, then log out/back in to your unprivileged account.

I am not sure if I quite understand the difference.

If I use for example sudo nano /etc/fstab in my normal user account, elevating my user to root temporarily, in what way would that be more "compromising" to the system than log out and log into a root account and do the same thing there.

Isn't it that in both cases it is nano which will be run with root privilege? So if nano is compromised, won't it be doing harm no matter in which account it is running as root?

GrouchyGrape

neotux your logic is sound. Now maybe you can see why it's a bad security model of an OS to allow user to elevate to such a high level of permission.

Maybe this will make it more apparent why a user with high privilege is so dangerous: when I'm doing a penetration test of a network and I "pop a shell" on a normal user (non-elevated), my options are often very limited, but I typically don't do much more than use them to find a user that is elevated (root/local admin/domain admin). If they are elevated (using sudo or otherwise), I can effectively do whatever I want to the system/domain.

When you install an app, and it requires elevation to do so, you're running that app as root/local admin. You're giving it permission to do whatever it wants to your system.

On android/iOS, the user is not elevated in the same way and thus, apps have to behave in the sandbox the system tells them to play in. They can't just do whatever they want.

neotux

GrouchyGrape

GrouchyGrape When you install an app, and it requires elevation to do so, you're running that app as root/local admin. You're giving it permission to do whatever it wants to your system.

If I am not misunderstanding you, I think you may not be correct on this one.

When you install an application, let's say Firefox, it is the package manager (pacman, apt, dnf, zypper etc.) of the system which requires root (/elevated privilege). It needs it to unpack the package and write the files and folders into the appropriate locations into your system filesystem.

The application itself, in this case Firefox, won't acquire any root privilege in this process. it can't "do whatever it wants to your system". However it will have access to your home directory or other locations your user can read from or write to, for example a partition mounted somewhere in the filesystem for storing data.

There are tools that you can use to limit what your user application can have access to. They may all have some pros and cons but that's not the point here.

According to what I understand from your statement, if I install Firefox, needing to run my package manager as root, I am giving it (Firefox) elevated privilege to do whatever it wants. This is not the case.

You could verify this by filtering htop for example to show root and user processes. You would never see Firefox running as root unless you have explicitly run it with sudo firefox which is a terrible mistake.

I can understand that the user application you install in your system are not properly sandboxed out of the box in your Linux box as they are on Android, but that doesn't mean they run as root and can do whatever they want.

Now, if you use a command line tool to perform some task, for example systemctl to start a system service x.service. You will have to do this as root. Now I fail to see what difference would it make to run it from your user account with sudo or log in to a root account using the same. If x.service or systemctl itself are compromised, this will cause harm to your system no matter where it is run from.