On most distributions I've seen, SELinux is configured to automatically label /proc files with labels based on fairly granular roles, so that setup already exists.
If you want to completely remove the global information in /proc you can do so by mounting it with subset=pid (and extra points for hidepid=4). This was added to improve container runtime security but unfortunately a lot of programs still depend on reading global procfs files so we can't enable it by default.
As for why all this information exists in /proc, procfs has historically been a bit of a dumping ground. There is an argument for "everything is a file" and so on, but having had to deal with all sorts of insane bugs related to procfs I'm less sympathetic to that argument than I used to be.
> There is also a catch that the program can create a new unprivileged user namespace and mount /proc there thus bypassing my daemon completely. Anyone can create a user namespace nowadays.
There actually are some restrictions, if the process doesn't have access to an unmasked procfs mounting /proc will fail, though a recent patch[1] finally made it so that subset=pid works in this case. (And most sandboxes disallow unprivileged CLONE_NEWUSER with seccomp.)
I also wanted to limit access to files/directories inside /proc/PID, or provide fake data. The /proc/PID also contains too many data.
Also, I might want to provide some fake data, for example, if app relies on reading /proc/cmdline or /proc/cpuinfo. So the app should be able to read the files, but not the real data.
> And most sandboxes disallow unprivileged CLONE_NEWUSER with seccomp
I ma worried that some applications (like Chrome, Electron-based apps) might not work without user namespaces. GTK uses "glycin" library, it launches subprocesses for handling images in a bwrap-based sandbox, and it broke inside my sandbox, so I had to do quick fixes for it.
No, sandboxing in Linux is not easy. Just look at "man capabilities" or "man user_namespaces" and see how many rules and exceptions from rules are there. You need to understand it if you write a sandbox, but it is so complicated. And obviously AI cannot be trusted with such a responsible task.
By the way I just read about OpenAI model breaking into Hugging Face and it used "cat /proc/self/mountinfo" to collect information about third-party sandbox it wanted to break from [1]. So my intuition that these files should not be accessible to the sandboxed program, was correct.
If you want to completely remove the global information in /proc you can do so by mounting it with subset=pid (and extra points for hidepid=4). This was added to improve container runtime security but unfortunately a lot of programs still depend on reading global procfs files so we can't enable it by default.
As for why all this information exists in /proc, procfs has historically been a bit of a dumping ground. There is an argument for "everything is a file" and so on, but having had to deal with all sorts of insane bugs related to procfs I'm less sympathetic to that argument than I used to be.
> There is also a catch that the program can create a new unprivileged user namespace and mount /proc there thus bypassing my daemon completely. Anyone can create a user namespace nowadays.
There actually are some restrictions, if the process doesn't have access to an unmasked procfs mounting /proc will fail, though a recent patch[1] finally made it so that subset=pid works in this case. (And most sandboxes disallow unprivileged CLONE_NEWUSER with seccomp.)
[1]: https://lore.kernel.org/linux-fsdevel/cover.1626432185.git.l...