Remove common-auth pam customizations

[emkll]

Status

Ready for review

Description of Changes

PAM customizations were necessary to allow 2FA for console logins. Since, these configurations are no longer necessary due to the phasing out of 2FA for console logins and /var/log/auth.log in trusty and syslog in xenial, (encryptfs.so), let's replace the FPF-configuredpam.d/common-auth file with the upstream-maintained common-auth.

Closes #3963 for new installs or installs on which ./securedrop-admin install is run.

Testing

• Ensure /etc/pam.d/common-auth provided by this PR is consistent with the upstream version(s) in Ubuntu 14.04 and 16.04.

Clean install

• Provision a Trusty staging environment (e.g. molecule converge -s libvirt-staging) and ensure SSH access is preserved on app and mon servers.
• Provision a Xenial staging environment (e.g. molecule converge -s libvirt-staging-xenial) and ensure SSH access is preserved on app and mon servers.
• Error message /lib/security/pam_encryptfs.so: cannot open shared object file: No such file or directory does not appear in /var/log/auth.log (Trusty) or journalctl -e (Xenial) does not contain after running the playbooks.

Upgrade testing

• git checkout develop
• Provision a Prod environment on develop (using./securedrop-admin install)
• Check out this branch and re-run ./securedrop-admin install
• Ensure ssh access is preserved on app and mon servers.
• Error message /lib/security/pam_encryptfs.so: cannot open shared object file: No such file or directory does not appear in /var/log/auth.log (Trusty) or journalctl -e (Xenial) does not contain after running the playbooks.

Deployment

Since there is no negative impact on running instances (Trusty or Xenial) other than errors in the logs, let's minimize the risk to automatically patch the file on running instances via postinst, and instead only ship this change via Ansible:

1. Existing production installs will be updated via Ansible
2. New installs via Ansible.

Checklist

If you made changes to the system configuration:

• Configuration tests pass

If you made non-trivial code changes:

• I have written a test plan and validated it for this PR

[conorsch]

Started reviewing this, haven't run through all the steps yet. On the surface this looks like exactly what what we want. On clean Trusty & Xenial VMs (i.e. before any SD-specific customizations are applied), the /etc/pam.d/common-auth files match what's presented here, with the small exception of pam_cap missing from the Trusty config, which was already discussed in #3963.

After verifying the rest of the functionality as described, I foresee two small additions:

• config test to check that ecryptfs does not appear in /etc/pam.d/common-auth
• config test to check that the log message does not appear in /var/log/auth.log

Before adding the latter test in particular, I'll a) confirm that the log message readily appears on develop and b) paste example log lines into #3963 to use in structure the test.

[codecov-io]

Codecov Report

Merging #4021 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           develop   #4021   +/-   ##
=======================================
  Coverage     84.7%   84.7%           
=======================================
  Files           43      43           
  Lines         2765    2765           
  Branches       300     300           
=======================================
  Hits          2342    2342           
  Misses         355     355           
  Partials        68      68

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1c877f7...3cb6d5c. Read the comment docs.

[conorsch]

Thanks for the tests and the rebase, @emkll. Verified that there are no unwanted side-effects on the Trusty story, and all config tests are passing locally.

For Xenial, SSH functionality is working as expected, and all the config tests are passing (except #3916, since I ran several provisioning commands). However, I'm I notice that auth.log contains:

/lib/security/pam_cap.so: cannot open shared object file: No such file or directory

Given that the pam_cap include was taken from the upstream config, and no problems were observed with SSH access, I suggest we ignore this for now and move forward with the other migration tasks.

[conorsch]

Approving for merge, especially with the shiny new tests.

For the record, I have not run through the upgrade portion of the test plan, but based on the positive results of both the Trusty and Xenial flows, I'm confident based on visual review that the config changes here work as advertised.