Russ Allbery <r...@debian.org> writes:
> [⋯]
> 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.
I broadly agree.
The fine details will be a bit annoying, though
that might be fixable by pushing some helper tools into systemd.
> (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.)
This last bit would be nontrivial to get 100% perfectly correct, but
I think we could get it 95% correct, and have debian/NEWS inform users
"if you're edge case X, do workaround Y".
An edge case I can think of is daemons that fork+exec other daemons.
For example, libvirtd may run qemu-system-x86_64, which may run smbd.
You could trigger that if you did manually added manual CLI options to "virsh
edit my-cool-vm":
<qemu:commandline>
<qemu:arg value="-net" />
<qemu:arg value="-user,smb=/opt/share" />
</qemu:commandline>
If all of that happens in a single systemd .service (which, admittedly, it
probably DOESN'T),
and qemu's minimal smbd instance uses /etc/pam.d/samba (which, admittedly, it
probably DOESN'T),
then libvirtd.service's hardening will apply to libpam_foo.so called by
/etc/pam.d/samba.
I can't think of a detector that could notice in advance the libvirtd.service
was gonna use samba pam rules.
As someone who does that kind of thing a lot, I'd rather have
the increased annoyance of opt-out hardening than
the reduced security of opt-in hardening.
Even if it means I occasionally need to patch site-local rules into
/etc/apparmor.d/local/usr.bin.msmtp or
/etc/systemd/system/libvirtd.service.d/override.conf.
