PAM should not be configured via files in `/usr/share/pam-configs`

[cmhe]

In the os-hardening role PAM seems to be configured using the /usr/share/pam-configs here, which are not configuration files, but directly package files.

According to the PAM Config Framework Specification those files aren't meant to be configured by the user:

• Package config declarations are shipped in the packages in /usr/share/pam-configs, and are not user-editable.
  • no intention to support multiple paths for these configurations; if users want to make changes that are not tied to a package, they should do so directly in the PAM configs

This also means that package updates will overwrite changes to these files.

[rndmh3ro]

@schurzi, should we move these?

[schurzi]

I kind of like the solution with placing the files into /usr/share/pam-configs.

From my standpoint we are a acting like a package. We provide preconfigured settings, that don't need to be changed by a user. We also don't overwrite any files that are distributed by Debian packages. So this should be safe to update. And in fact I did a lot of tests with the last Debian stable release and this was never an issue.

In general, we have many problems with RHEL based distributions simply because we are placing predefined files in /etc/pam.d. The current solution for Debian works really well with users editing their local PAM configuration.

So it is true, that the framework specifies, that a user should not touch the files in /usr/share/pam-configs. We are creating our own files an we are not touching any other files, which belong to a Debian package. We also expect our users to not modify these files without using our Ansible collection. While we are clearly not a Debian package and there might be name collisions in the future, I really like to keep the current implementation.

[cmhe]

Well there is /usr/share/pam-configs/passwdqc which is deployed by the os_hardening role, but belongs to libpam-passwdqc package.

So it causes:

$ dpkg --verify libpam-passwdqc
??5??????   /usr/share/pam-configs/passwdqc

for a non-config file.

[setpill]

Stumbled across this while working on some distributed pam configs myself. I agree with schurzi that "acting like a package" is the correct thing to do here. The name collision is indeed a bug, then, which can be sidestepped by prefixing the filename with something vendor specific, e.g. renaming to /usr/share/pam-configs/devsecio-passwdqc.