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.
2
3
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.
On a desktop or server, you can use systemd unit extension files to put services in the supplementary group. It's needed by logind among others.
/etc/systemd/system/systemd-logind.service.d:
[Service]
SupplementaryGroups=proc
A lot of desktop stuff has issues with it though.
1
2
Replying to
Much appreciated. I'm basically trying to consider options for protecting a process in Linux from other (possibly root) processes. Seems like there are a number of capabilities - memfd_secret, hidepid, LSM of course, ptrace restrictions.
1