3 ms·

How do you write SELinux policies to allow reading only certain files in /proc, where process IDs are not known ahead? I ended up writing my own FUSE-based /pro

How do you write SELinux policies to allow reading only certain files in /proc, where process IDs are not known ahead? I ended up writing my own FUSE-based /proc emulation. The facilities are there, but it feels like writing your own OS.

jolmg 2mo ago
What kind of use-case do you have for that? I suppose whatever it is, you could also e.g. write a privileged service that checks those files with whatever security policy you need. Your client wouldn't have direct access to /proc. Another option may be to set up a container or PID namespace and give your tool direct access to that /proc. Regarding SELinux, looking at https://unix.stackexchange.com/questions/767564/selinux-denies-to-access-file-in-proc https://unix.stackexchange.com/questions/767564/selinux-deni... > the entries under /proc/<pidnr>/ are running under the respective pid's domain It also seems doable, since you can differentiate which PID directory belongs to what by the domain.
- codedokode 2mo ago
  The /proc contains too many unnecessary information, which can be used for fingerprinting or helping an attack. Run `ls /proc` and find yourself surprised. For example, why do applications need to know the kernel command line? What for? Why do they need the list of major and minor device numbers? List of filesystems? Network configuration? So I want to follow the principle of minimal privileges and only grant access to files needed for running a program. Sadly many programs cannot run without /proc. For example, poorly coded Apple's Grand Central Dispatch library crashes the application (for example, Telegram) if it cannot enumerate the information about threads or processes. It needs this information to calculate how many additional worker threads need to be created, and if it cannot calculate the number, it terminates the application for reasons I do not understand. 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. > Another option may be to set up a container or PID namespace and give your tool direct access to that /proc. /proc contains information not only about processes, but a lot of extra information.
  - jolmg 2mo ago
    It sounded like your problem was restricting access to some /proc/<pid>/ dirs and not others without knowing the PIDs ahead of time: > How do you [...] allow reading only certain files in /proc, where process IDs are not known ahead? Such things like /proc/cmdline should be even easier. You can just set regular DAC permissions and ownership on such files. You can just set ACLs on such files. > There is also a catch that the program can create a new unprivileged user namespace and mount /proc there thus bypassing my daemon completely. You don't get the ability to mount just because you created an unprivileged user namespace. > For example, why do applications need to know the kernel command line? What for? Why do they need the list of major and minor device numbers? List of filesystems? Network configuration? Because you might ask them to get that info. If you wouldn't have a use for that, you prevent that using one of a number of security mechanisms, including writing your own SELinux policy where you don't whitelist that access, setting DAC permissions and ownership as such, ACLs as such, etc. Applications compose and are heavily configurable, and they include such things like language interpreters. You may want to write a script that uses any of that info for whatever. You may want e.g. your window manager to show that info on a statusbar periodically. That info can also be useful for conky or htop, etc. Vim is a text editor, but you can e.g. have it make a call with ssh to get info from wherever and put that info into the buffer. You can say that a text editor doesn't have a need to read network configurations, but maybe by composing with ssh it does, and it does something useful with it.
    - codedokode 2mo ago
      > You can just set ACLs on such files. I am not sure if I can set ACL or ownership on /proc files, it is not a disk-based filesystem. > You don't get the ability to mount just because you created an unprivileged user namespace. Please consult "man user_namespaces", section "Effect of capabilities within a user namespace". It clearly says that one can mount /proc inside a mount namespace governed by a user namespace without being root. The reason why you weren't aware is probably because the rules related to namespaces and capabilities are extremely complicated. > Vim is a text editor, but you can e.g. have it make a call with ssh to get info from wherever and put that info into the buffer. I definitely do not want proprietary applications running ssh on my system without me knowing.

jolmg 2mo ago

What kind of use-case do you have for that? I suppose whatever it is, you could also e.g. write a privileged service that checks those files with whatever security policy you need. Your client wouldn't have direct access to /proc. Another option may be to set up a container or PID namespace and give your tool direct access to that /proc. Regarding SELinux, looking at https://unix.stackexchange.com/questions/767564/selinux-denies-to-access-file-in-proc https://unix.stackexchange.com/questions/767564/selinux-deni... > the entries under /proc/<pidnr>/ are running under the respective pid's domain It also seems doable, since you can differentiate which PID directory belongs to what by the domain.

codedokode 2mo ago
The /proc contains too many unnecessary information, which can be used for fingerprinting or helping an attack. Run `ls /proc` and find yourself surprised. For example, why do applications need to know the kernel command line? What for? Why do they need the list of major and minor device numbers? List of filesystems? Network configuration? So I want to follow the principle of minimal privileges and only grant access to files needed for running a program. Sadly many programs cannot run without /proc. For example, poorly coded Apple's Grand Central Dispatch library crashes the application (for example, Telegram) if it cannot enumerate the information about threads or processes. It needs this information to calculate how many additional worker threads need to be created, and if it cannot calculate the number, it terminates the application for reasons I do not understand. 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. > Another option may be to set up a container or PID namespace and give your tool direct access to that /proc. /proc contains information not only about processes, but a lot of extra information.
- jolmg 2mo ago
  It sounded like your problem was restricting access to some /proc/<pid>/ dirs and not others without knowing the PIDs ahead of time: > How do you [...] allow reading only certain files in /proc, where process IDs are not known ahead? Such things like /proc/cmdline should be even easier. You can just set regular DAC permissions and ownership on such files. You can just set ACLs on such files. > There is also a catch that the program can create a new unprivileged user namespace and mount /proc there thus bypassing my daemon completely. You don't get the ability to mount just because you created an unprivileged user namespace. > For example, why do applications need to know the kernel command line? What for? Why do they need the list of major and minor device numbers? List of filesystems? Network configuration? Because you might ask them to get that info. If you wouldn't have a use for that, you prevent that using one of a number of security mechanisms, including writing your own SELinux policy where you don't whitelist that access, setting DAC permissions and ownership as such, ACLs as such, etc. Applications compose and are heavily configurable, and they include such things like language interpreters. You may want to write a script that uses any of that info for whatever. You may want e.g. your window manager to show that info on a statusbar periodically. That info can also be useful for conky or htop, etc. Vim is a text editor, but you can e.g. have it make a call with ssh to get info from wherever and put that info into the buffer. You can say that a text editor doesn't have a need to read network configurations, but maybe by composing with ssh it does, and it does something useful with it.
  - codedokode 2mo ago
    > You can just set ACLs on such files. I am not sure if I can set ACL or ownership on /proc files, it is not a disk-based filesystem. > You don't get the ability to mount just because you created an unprivileged user namespace. Please consult "man user_namespaces", section "Effect of capabilities within a user namespace". It clearly says that one can mount /proc inside a mount namespace governed by a user namespace without being root. The reason why you weren't aware is probably because the rules related to namespaces and capabilities are extremely complicated. > Vim is a text editor, but you can e.g. have it make a call with ssh to get info from wherever and put that info into the buffer. I definitely do not want proprietary applications running ssh on my system without me knowing.