Philipp Kern <pk...@debian.org> writes: > My fear here would be that you are not in control of what your > dependencies are doing. This is especially true if you think of NIS and > PAM, where libraries are dlopen()ed and can spawn arbitrary helper > binaries. I remember openssh installing a syscall filter for its auth > binary and then it failed with certain PAM modules (see also your > allow_ypbind example). So we should also not be too limiting when > sandboxing daemons.
I am hesitant to propose work that I personally will not have time to work on, but that feels like a place where Debian, as a distribution, could add a great deal of value. We know which PAM modules are installed and can analyze the PAM configuration files to know which ones are configured. We know which daemons use PAM. We similarly know which NSS modules are enabled. We can figure out what facilities they require, and could automate adding additional permitted facilities to a locked-down base configuration, so when you enable a PAM module that requires some functionality, it automatically updates the systemd configuration of all of the daemons that use PAM. (And of course additional narrowing to just the daemons that are configured to use that PAM module is possible if we know which PAM name the daemon uses.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
