Implement automatic unlocking though a systemd service

[josephlr]

Right now, both automatic unlocking of directories and rewrapping of the user's login protector are done though the PAM module pam_fscrypt.so. Specifically the following PAM types do the following things:

• session
  • tracks of the number of open sessions for that user
  • automatically unlocks user encrypted directories
  • automatically locks user encrypted directories (on the last logout)
• auth forwards the AUTHTOK object as part of the PAM data (if necessary)
• password rewarps the login protector (if necessary)

The basic plan is to keep the auth and password types in the pam modules (with modifications), while doing all the stuff we do in session in fscrypt@.service.

@ebiggers, @tyhicks: I'd love your feedback on the basic idea (and if it would improve things).
@fancytenseletters, @Minecrell, @sebadoom: This should (hopefully) fix some of the bugs you've reported.

Justification

Bugs #66, #77, #93, #196 (#57 and #34 are also related) seem to be bugs around what order certain operations run in. Ideally, we want all of our setup to happen before any user task starts. Similarly, all our teardown should occur after all user tasks complete. To do this well, we need to integrate with the OS's init service. This is because the init service:

• knows when the first session of a user begins
• knows when the last session ends
• allows us to run fscrypt commands at specific points to prevent things from breaking

eCryptfs has been running into issues with systemd and automatic mounting via PAM modules. See: Arch Bug, Debian Bug, Ubuntu Bug, systemd Bug. pam_mount.so, which can do similar stuff for device encryption, has also had issues.

Details

This change would require changing or adding three things.

• Remove functionality from pam_fscrypt.so

  • Remove session hooks, keyring linking code, caches code, etc..
  • For auth, if the user has a login protector, use the passphrase to unlock the login protector, and store it in the root user keyring (with type user). We could also prompt the user here to enter their old login password if things have gotten out of sync.
  • For password, if we find a login protector, use the passphrase hashes of AUTHTOK and OLDAUTHTOK to update the login protector to update the login protector

• Add new commands to fscrypt that must be run as root:

  • fscrypt system start <uid> --unlock=[none|login] [--link-to-root]
    • --unlock adds policies to the user's keyring
      • login gets the login protector key from the root user keyring and uses it to unlock the corresponding policies
    • --link-root-keyring makes sure the user keyring is linked into the root user keyring
  • fscrypt system stop <uid> --lock=[none|login|all] [--drop-caches] [--unlink-from-root]
    • --lock removes policies from the user's keyring:
      • login removes just those protected by the login passphrase
      • all removes all policies in the user's keyring
    • --drop-caches calls DropFilesystemCache after all keys are removed
    • --unlink-from-root removes the user keyring from the root user keyring

• Add a systemd service to trigger the appropriate commands. For example:

[Unit]
Description=Unlock fscrypt directories with login credentials
Before=user@%i.service

[Service]
Type=oneshot
RemainAfterExit=yes
Slice=user-%i.slice
RemainAfterExit=yes
StandardOutput=jouranal
StandardError=syslog
SyslogIdentifier=fscrypt
ExecStart=/usr/bin/env fscrypt system start %i --unlock=login --link-to-root
ExecStop=/usr/bin/env fscrypt system stop %i --lock=all --drop-caches --unlink-from-root

[Install]
WantedBy=user@%i.service

Benefits

• Way less PAM code to maintain
  • No more tracking the number of open user sessions
  • No locking/unlocking of directories
  • No keyrings or caching related code
  • Could replace how we currently check the user password eliminating our custom conversation function
  • Keeps the Pluggable Authentication Module focused on authentication related stuff.
• More stability
  • Should load before a lot of login jobs, preventing bugs with SDDM/GDM
  • Better setup to handle user session failures (right now we just never trigger cleanup)
  • Will eliminate issues with user processes keeping files open (mentioned here).
• Allows for more complex configuration than the PAM config files
• Allows behavior in [question] user keyring still linked to root keyring after fscrypt purge command #60 to be easily configurable
• No ties to systemd in particular. Any init service can call fscrypt system [start|stop] <uid>.

It should be password pam module type, not passwd.

[josephlr]

@fancytenseletters Fixed, Thanks!

[lathiat]

I'm not sure if this is the right place to put this, but I wanted to comment here because it may be relevant to whether this is the correct fix path.

I've discovered the main pain point for getting libpam-fscrypt to work on Ubuntu currently is that /etc/pam.d/systemd-user does not call into pam_keyinit.so - so the session keyring is not linked to the user keyring, and that causes libpam-fscrypt to appear to fail.

Something non-obvious about this, is that many desktop session processes are started under 'systemd-user' instead of the actual 'desktop session' - this includes gnome-terminal-server which means any gnome-terminal shell runs under this context. If you start xterm instead of gnome-terminal, you get a process under the session slice and a different keyring and this can cause confusion when debugging the issue as some processes are in one state and the others are in another including your primary debug tool gnome-terminal. You can verify this by running 'systemctl status $(pidof gnome-terminal)' and 'systemctl status $(pidof xterm)' and note the different hierachy.

In this example case within gnome-terminal you have no access to your homedir but within xterm you do.

The change to add pam_keyinit.so was made upstream in December 2016:
systemd/systemd@ab79099

However it is not currently reflected in Debian Stable or Ubuntu 16.04 through 18.04. You can find related bugs here and I also put a lot more detail into the launchpad bug below:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1754270
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846377

With some feedback I'd be happy to open this as a new issue or similar as I guess at a minimum documentation probably could be updated to reflect needing to ensure pam_keyinit.so is in /etc/pam.d/systemd-user -- but otherwise unsure how this might effect these plans to change the mechanism entirely.

I am far from a PAM expert, learnt most of it debugging this issue, but I'd be happy to have a conversation with anyone not quite understanding how systemd-user and the other session processes are interacting and how it's all relevant. Otherwise perhaps check my full write-up at https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1754270

[ebiggers]

I'm not sure this should be fixed by adding a systemd service for fscrypt. Other than people just not configuring pam_fscrypt correctly, I think the main problem here is that systemd is opening a PAM session for each systemd-user "session", but then not closing it properly. There are two problems with how systemd is closing the PAM session. First, it is incorrectly being closed with dropped privileges, which breaks PAM modules that need to do privileged operations when closing the session, such as unmounting filesystems; or, in the case of fscrypt, writing to /var/run/fscrypt/ or executing the drop_caches sysctl. And secondly, there is a race condition where systemd sends SIGKILL to the process "(sd-pam)" which is executing pam_close_session(), so not all the PAM modules are guaranteed to be run.

It's possible to partially work around this for pam_fscrypt by changing /etc/pam.d/systemd-user to not run the pam_fscrypt hook. For example, on Arch Linux put the pam_fscrypt hooks in system-login (not system-auth), then replace the 'session include system-login' line in systemd-user with the corresponding 'session' lines from system-login, with pam_fscrypt removed. That way, systemd-user would neither increment nor decrement the refcount for fscrypt, so your directories will be "locked" at logout again (although even if you are actually still running a background process through systemd-user, which isn't right).

I think this really needs to be fixed in systemd so that it works for everyone including other PAM modules such as pam_ecryptfs, pam_mount, etc...

[ebiggers]

@josephlr, @tyhicks: I've opened an issue for the underlying systemd bug here: systemd/systemd#8598

For example, on Arch Linux put the pam_fscrypt hooks in system-login (not system-auth), then replace the 'session include system-login' line in systemd-user with the corresponding 'session' lines from system-login, with pam_fscrypt removed

@ebiggers There are cleaner tricks already discussed in #77 (comment)

session [success=1 default=ignore]  pam_succeed_if.so  service = systemd-user quiet
session    optional   pam_fscrypt.so       drop_caches lock_policies

[HerroBert]

No, don't wire that to systemd!

I think it would be great to have fscrypt@.service regardless of linked systemd ticket status - it would make troubleshooting user's setup much easier because 'journalctl --user-unit fscrypt@user.service' is much less arcane than debugging PAM module logic.