Ever since the first release of the Android N developer preview, I get "permission denied" errors when attempting to list the root directory or other system directories. The permissions on these directories didn't seem to change (as far as I can tell).
What change(s) in Android N caused these permission denied errors?
How to replicate:
In ADB shell, run the following commands:
run-as com.debuggable.packagename ls /
This gives permission denied errors on Android N.
Why list system directories:
I noticed this behavior on Android N with several file managers. They could no longer list the root directory or other system files. This also is limiting the output of running ps
in a shell. The changes also caused this library to stop working on Android N.
Today, we'll begin rolling out Android 7.0 Nougat to Nexus devices. And with more ways to make Android your own, it's by far our sweetest release yet.
Verdict. Overall Android 7.0 Nougat is a great update. It makes some significant changes under the hood that provide benefits including longer battery life. The visual tweaks are subtle and most will likely be masked by the customisations made to Android by third-party manufacturers.
Devices that will get Nougat across their versions include the Galaxy S7, Galaxy S7 Edge, Galaxy Note 5, Galaxy S6, Galaxy S6 Edge, Galaxy S6 Edge Plus, Galaxy Tab A with S Pen, Galaxy Tab S2 (LTE), Galaxy A3, and Galaxy A8.
There were two groups of changes reducing access to /proc.
The procfs filesystem is now mounted with hidepid=2, eliminating access to the /proc/PID directories of other users. This change was implemented in CopperheadOS and was then adopted upstream based on it. There's a group for making exceptions but it's not exposed as a permission. It's only used to make exceptions for some processes in the base system. It could be exposed as a 'dangerous' permission and it's what I expected Google would end up doing but they decided that users wouldn't understand the implications of it.
https://android-review.googlesource.com/#/c/181345/
SELinux policies also became much stricter. For apps, there's no baseline access to /proc at all anymore, although that only applies to files other than the /proc/PID directories. There's still access to a few files with labels not falling under the general proc policy, but it's mostly gone. This has been gradual and there are many relevant commits. One of the big ones:
https://android-review.googlesource.com/#/c/105337/
This not only removes a lot of obvious information, but it also closes some more blatant security holes involving side channels allowing things like logging keyboard input:
SELinux policies have also become a lot stricter in general over time. You can see the rest of that in the platform/system/sepolicy repository. Note that it was at platform/external/sepolicy for a long time but it was recently moved.
This was done for security and privacy reasons. From the bug report:
In the case of the root (/) and /sys filesystems, a directory listing is not possible.
The official answer from Google:
The behavior you're describing is working as intended. Android provides strict sandboxes that applications must run in. These sandboxes protect application data from other applications, including application metadata such as process state.
/sys and /proc are well known for leaking side channel information about processes, information which can be used to infer state about the processes. For instance, it's been documented for years that /proc access can be used to monitor for app launching, enabling phishing attacks.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With