I use GrapheneOS without play services on my daily driver because I despise Google’s forcing play services down Android’s throat. The irony isn’t lost on me that Graphene only works on Google devices, that will hopefully change soon as Graphene works with an OEM to build their own devices. I don’t bother with banking or government apps as they aren’t mandatory where I live, at least not yet. I try to stick to FOSS (or at least source available) apps where possible.
On a secondary device I also run a rooted version of GrapheneOS just for fun. Yes I know it might be viewed as terribly insecure but it’s just a secondary device that I like to play around with, it doesn’t have any important data on it. I find it quite interesting to learn how rooting methods work to bypass the normal security measures in place.
It’s important to point out that security isn’t binary. Things aren’t simply “secure” or “insecure”. Rather, there are certain classes of vulnerabilities that are present in some systems and absent in others.
Typical PC operating systems don’t have the app sandboxing prism’s comment mentions at all, and do have a way for apps to prompt to ask for administrative access. A phone with root is somewhere between the two; apps are usually sandboxed, but if you give them root (or they get it with an exploit), then they’re not.
If a PC is secure enough for a certain use case, an Android phone with root probably is as well. Either one calls for a bit of caution with regard to the apps you install.
That’s true on modern Android even with root. The active OS partition can’t be modified while running, and updates install to the inactive slot. If the bootloader is unlocked, malware could theoretically act as an updater and install itself to the inactive slot, but I’m not sure that has been seen in the wild.
It’s theoretically possible to have a locked bootloader and root. That requires a device with a re-lockable bootloader like a Pixel, and a ROM that has root support built in to the signed image.
Rooting devices breaks the principle of sandboxing: one app shouldn’t be able to access or modify another app or its data, or system files. If you give an app root, it can do whatever it wants to the system. It could install a keylogger to steal credentials, extract login tokens from another app’s storage or just nuke system files to make your device unbootable.
Let’s say you don’t give any apps root. Even having a rooting platform on the phone (e.g. Magisk) is still a vulnerability. Most rooting platforms will ask the user whether an app should get root when the app requests it. But there could be code execution vulnerabilities (e.g. buffer overflows) in the rooting platform that let you add an app to the list of apps allowed to use root without user confirmation.
TLDR: Root gives an app full access to the device, it could do anything with that. Even if you’re careful with what you give root to, it still adds a lot of attack surface that could be exploited.
It would be great if we had a fine-grained access control mechanism where the user could specify that AccA may write to anything in /sys/class/power\_supply and AdAway may write to /etc/hosts, but neither can access any *other* system files. Apps that use root almost always need a fairly narrow set of elevated privileges.
Android already has everything it needs to support that under the hood with SELinux. A UI for it would allow users full control of their devices with a reduced attack surface area.
KernelSU has something like this called app profiles where you can set the capabilities that each app gets when it uses su. And if you are a SELinux wizard you can also set a custom domain for each app which would give you the fine grained control you’re looking for. I doubt the average KernelSU user wants to delve into SELinux details so some tool to automate this would be cool.
Sadly doesn’t look like Magisk supports this.
I use GrapheneOS without play services on my daily driver because I despise Google’s forcing play services down Android’s throat. The irony isn’t lost on me that Graphene only works on Google devices, that will hopefully change soon as Graphene works with an OEM to build their own devices. I don’t bother with banking or government apps as they aren’t mandatory where I live, at least not yet. I try to stick to FOSS (or at least source available) apps where possible.
On a secondary device I also run a rooted version of GrapheneOS just for fun. Yes I know it might be viewed as terribly insecure but it’s just a secondary device that I like to play around with, it doesn’t have any important data on it. I find it quite interesting to learn how rooting methods work to bypass the normal security measures in place.
What make a rooted phone insecure?
It’s important to point out that security isn’t binary. Things aren’t simply “secure” or “insecure”. Rather, there are certain classes of vulnerabilities that are present in some systems and absent in others.
Typical PC operating systems don’t have the app sandboxing prism’s comment mentions at all, and do have a way for apps to prompt to ask for administrative access. A phone with root is somewhere between the two; apps are usually sandboxed, but if you give them root (or they get it with an exploit), then they’re not.
If a PC is secure enough for a certain use case, an Android phone with root probably is as well. Either one calls for a bit of caution with regard to the apps you install.
Non rooted phones usually have read-only OS partition so even if malware is present, it can’t affect the OS itself
That’s true on modern Android even with root. The active OS partition can’t be modified while running, and updates install to the inactive slot. If the bootloader is unlocked, malware could theoretically act as an updater and install itself to the inactive slot, but I’m not sure that has been seen in the wild.
It’s theoretically possible to have a locked bootloader and root. That requires a device with a re-lockable bootloader like a Pixel, and a ROM that has root support built in to the signed image.
Rooting devices breaks the principle of sandboxing: one app shouldn’t be able to access or modify another app or its data, or system files. If you give an app root, it can do whatever it wants to the system. It could install a keylogger to steal credentials, extract login tokens from another app’s storage or just nuke system files to make your device unbootable.
Let’s say you don’t give any apps root. Even having a rooting platform on the phone (e.g. Magisk) is still a vulnerability. Most rooting platforms will ask the user whether an app should get root when the app requests it. But there could be code execution vulnerabilities (e.g. buffer overflows) in the rooting platform that let you add an app to the list of apps allowed to use root without user confirmation.
TLDR: Root gives an app full access to the device, it could do anything with that. Even if you’re careful with what you give root to, it still adds a lot of attack surface that could be exploited.
@prism @Twakyr
It would be great if we had a fine-grained access control mechanism where the user could specify that AccA may write to anything in
/sys/class/power\_supplyand AdAway may write to/etc/hosts, but neither can access any *other* system files. Apps that use root almost always need a fairly narrow set of elevated privileges.Android already has everything it needs to support that under the hood with SELinux. A UI for it would allow users full control of their devices with a reduced attack surface area.
KernelSU has something like this called app profiles where you can set the capabilities that each app gets when it uses su. And if you are a SELinux wizard you can also set a custom domain for each app which would give you the fine grained control you’re looking for. I doubt the average KernelSU user wants to delve into SELinux details so some tool to automate this would be cool. Sadly doesn’t look like Magisk supports this.