[xenial] Investigate if PAM common-auth customizations are still needed

[eloquence]

The PAM common-auth customizations include declarations for pam_ecryptfs.so which prove problematic on Xenial; commenting out appears to resolve. More research required. We may be able to remove these additions entirely, now that we no longer support 2FA via challenge-response.

Part of #3204.

[emkll]

It seems like ecryptfs pam module [0] was and still is used by Ubuntu's encrypted home directory [1] functionality. The install documentation instructs users to not enable this feature [2].

Based on the above, I believe it's safe for us to remove this, perhaps making a note in the release notes that this was done, in case an organization has accidentally enabled this feature. Given the critical nature of this configuration file, we want to ensure its state is consistent and predictable across installed:

To be mindful of existing installs, using the suggested pam-auth-update [3] in the future to update this file may help ensure consistency. After analyzing a common-auth file on a clean 14.04.05 install, without ecryptfs module, SecureDrop's current common-auth is identical, with the exception of the optional pam_cap module [4]. pam_cap.so is used restrict kernel capabilities to certain users, which SecureDrop currently does not use. Since it's optional and, it would be fine to include.

[0] https://help.ubuntu.com/lts/serverguide/ecryptfs.html
[1] https://help.ubuntu.com/community/EncryptedHome
[2] https://docs.securedrop.org/en/latest/servers.html?#continue-the-installation
[3] http://manpages.ubuntu.com/manpages/precise/man8/pam-auth-update.8.html
[4] :

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
auth	[success=1 default=ignore]	pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth	requisite			pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth	optional			pam_cap.so 
# end of pam-auth-update config

[emkll]

If we decide to remove this config option, I see two options:

1. Remove the common-auth from the repo and remove the copy action in install_files/ansible-base/roles/restrict-direct-access/tasks/ssh.yml. Provide unattended upgrades via postinst to existing instances.

2. Simply overwriting install_files/ansible-base/roles/restrict-direct-access/files/common-auth with the default Ubuntu-provided configuration, and phase out the config (see 1) after the Xenial migration.

Option 2 seems like the safest to me, if we can rely on admin intervention for the upgrade. Is it realistic to expect admins to run a securedrop-admin install to ensure their instances are up-to-date and configured properly?
If going with option 1, we should be very careful to remove this logic (and consider the same with any other now no-op lines as to not break configurations in the future.

[conorsch]

Agreed that the logic is no longer necessary. Since 0.3.1 (2015-03-23) we've explicitly recommended against encrypting the home directory, and for several releases prior to that, we stated that there was "no need" to encrypt the home directories. Given that breadth of time, we can rather safely assume that instances in the wild are not using the feature (cc @redshiftzero for visibility), in case we wanted to clean up on active systems—a solution to which option 1 above refers.

So, no concerns with removing the Ansible logic, as stated in option 2. As for cleaning up via postinst, we'd do well to have the most predictable system state possible going into the Xenial migration, so I'm inclined toward cleaning up.

The question becomes: is anything broken in regard to leaving this reference in place? #3519 notes that syslog reports problems with the line as currently structured even on Trusty. Over in #3491 (comment), I myself noted that I commented it out—presumably based on log messages, shame on me for not providing more detail. Given that #3491 (comment) and #3519 were filed on the same day, I suspect they're related to the same report, and not indicative of a wider problem.

If we cannot point to any specific breakage under Trusty or Xenial, then option 2 does seem quite reasonable, and our best course of action give the timelines we're working with for the migration.

[emkll]

The error described in the tickets above (/lib/security/pam_encryptfs.so: cannot open shared object file: No such file or directory" is indeed present in 14.04 (in /var/log/auth.log) They can be reliably triggered by logging in via console (but no longer via SSH since no longer uses PAM). These also generate OSSEC alerts. Nothing is broken, and the alert could be suppressed.

I think it would be more prudent to revert to the default upstream configuration in all cases.
We should:

• Remove common-auth action from install_files/ansible-base/roles/restrict-direct-access/tasks/ssh.yml

That should take care of new installs. For existing installs I see 2 options:

• Via postinst
• Handle the change in the (likely) upgrade playbook (including the default ubuntu 14.04 common-auth file)

If we are planning on having an upgrade playbook, the second option strikes me as the much safer one.

[conorsch]

Given the lack of functional problems reported during the Xenial testing, it seems fine to leave those files as-is for existing instances. Action to close out this ticket should be:

1. update ansible config logic with upstream config file
2. ensure ansible config supports both xenial and trusty

We still have a bit of config drift there, but resetting to the known good values is the safest action going forward, and doesn't involve hacky postinst scripts.

[conorsch]

Examples of failure output in log lines, to inform writing config regression tests in the PR to resolve:

root@app-staging:~# grep pam_ecrypt /var/log/auth.log 
Jan 11 19:42:26 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:26 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:28 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:28 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:28 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:28 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:28 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:28 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:30 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:30 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:30 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:30 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:31 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:31 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:31 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:31 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:31 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:31 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:32 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:32 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:33 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:33 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:33 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:33 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:33 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:33 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 19:42:34 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 19:42:34 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 20:04:04 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 20:04:04 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 20:04:04 app-staging su[3052]: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 20:04:04 app-staging su[3052]: PAM adding faulty module: pam_ecryptfs.so
Jan 11 20:08:26 app-staging sudo: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 20:08:26 app-staging sudo: PAM adding faulty module: pam_ecryptfs.so
Jan 11 20:08:26 app-staging su[3245]: PAM unable to dlopen(pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Jan 11 20:08:26 app-staging su[3245]: PAM adding faulty module: pam_ecryptfs.so

In particular it's the pam_ecryptfs string that should be absent.