Philipp Kern <pk...@debian.org> writes: > On 2023-07-05 09:36, Russell Coker wrote: >> On Monday, 3 July 2023 22:37:35 AEST Russell Coker wrote: >>> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
> 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 had this problem with PADL libpam-ldap, which loads an entire buggy LDAP client (and all of openssl!) into EVERY process. But that was fixed many releases ago with de Jong's nss-pam-ldapd, which merely has each process make an AF_UNIX connection to a separate process (nslcd). I think libnss-sss also works this way (AF_UNIX to sssd). For the specific NIS+ example my reaction was: Is anyone even still using NIS+? And if so, do they care about security AT ALL? They'll just disable systemd hardening on day 1, like they already do for selinux and apparmor. I agree that (almost) every frobozzd will use nss or pam, and the frobozzd maintainer can't stop the end user doing "apt install libnss-insane" and crashing frobozzd, because frobozzd.service hardening isn't compatible with libnss-insane. Because libnss-insane could do ANYTHING, and it'll do so within the Linux namespace/cgroup context of frobozzd.service. I think there's a reasonable middle ground, though. I think the number of libnss-insane packages that do TRULY wacky things are limited, and the number of people using them are small, and the inconvenience of them having to opt out (with "systemctl edit") is worth the improved security for everybody else. I think for most pam and nss packages, allowing (not blocking/hardening) AF_UNIX (e.g. sss, ldapd) and AF_NETLINK (e.g. systemd, mymachines, resolve) is probably going to cover it. Unfortunately I don't (yet) have any hard data to back up these feelings. PS: PADL is gone in Debian 12: https://tracker.debian.org/news/1424430/libpam-ldap-removed-from-testing/ PS: NIS is off(ish) by default in Debian 11+: https://wiki.debian.org/BullseyeNis PS: NIS+ seems to be in Debian 12, but deprecated https://salsa.debian.org/glibc-team/libnss-nisplus https://tracker.debian.org/pkg/libnss-nisplus PS: in theory if libnss-insane is known to break frobozzd, libnss-insane can pre-ship the errata for each daemon: libnss-insane-common_1-1_all.deb: /lib/systemd/system/frobozzd.service.d/libnss-insane.conf: # frobozzd.service ships with # SystemCallFilter=@system-service # SystemCallFilter=~@resource @resource # but libnss-insane needs access to nice(2) from @resource. # Add that to the allowlist. SystemCallFilter=nice but it would have to do that for EVERY affected .service. There isn't a way for libnss-insane to add a "global" allow rule.