I learned the other day about procfs 'hidepid', which restricts which parts of procfs a process can read.
tl;dr: setting procpid to 1 or 2 enforces that a process under user A can only see procfs directories for pids under user A.
wiki.gentoo.org/wiki/Procfs#Re
Conversation
Replying to
I helped to upstream hidepid=2 in Android a few years ago. It's largely obsoleted now that API 28+ apps each have a unique SELinux MLS context. It's still useful for API < 28 apps since their per-user MLS context allows them to see each other's processes within the same profile.
Replying to
That's awesome. I was planning to look into SELinux for similar enforcement as well, but I wanted to see what was available without any specific LSM.
1
Replying to
Can see where it's enabled here:
android.googlesource.com/platform/syste
init then gives itself the gid exception, and adb has and exception too:
android.googlesource.com/platform/syste
Also used to gate access to low-level IPC APIs offering similar information.
It's a nice example of how to deploy it.
2
Show replies
Fallout of app developers complaining about needing to use more restricted higher-level OS APIs gated by permissions like developer.android.com/reference/andr:
issuetracker.google.com/issues/37091475
There's a hidepid gid option used for internal exceptions but it's too coarse/problematic for a permission.
2
2
SELinux is also used to whitelist access to the individual /proc and /sys APIs. I helped push for /proc/net to be unavailable to most apps. It's only available for user authorized VPN service apps now. Only a couple very specific things in /sys are usable and debugfs is banned.
1