neithernut/pam_e4crypt

PAM module for unlocking transparently encrypted directories on ext4

pam_e4crypt's Issues

[Idea] Add an option for system-wide user specific salt

I'm sorry for constantly disturbing you but I wanted to share one more idea :)

Currently user can set her specific salt in ~/.ext4_encryption_salt which is unfortunately incompatible with encrypted $HOME directory. My idea is to add option to set system-wide salt directory like /var/e4crypt or /home/.e4crypt where pam_e4crypt will look for user salts instead taking precedence.

This option could be like this:
salt_path=$PATHNAME

User could setup it like this:

auth        required        pam_e4crypt.so salt_path=${PATHNAME}
session     required        pam_e4crypt.so salt_path=${PATHNAME}

I'm not sure if it needs to be set for both auth and session or for only one of them.

Now to be available for different users in case of salt_path is set, pam_e4crypt will look for $PATHNAME/$USERNAME-ext4_encryption_salt file instead of $HOME/.ext4_encryption_salt file.

Specific example:

auth        required        pam_e4crypt.so salt_path=/var/e4crypt
session     required        pam_e4crypt.so salt_path=/var/e4crypt

For user Bob pam_e4crypt uses salt from /var/e4crypt/Bob-ext4_encryption_salt
For user Alice pam_e4crypt uses salt from /var/e4crypt/Alice-ext4_encryption_salt

Unfortunately I can't help implementing this due to lack of programming skill but I can show you implementation of similar option in pam_yubico module. In this case the option name is chalresp_path and it overrides default $HOME/.yubico/

I hope above will help you in some way. What do you think about this?

Mention cron problems in documentation

Cronjobs for a user with an encrypted home folder of course fail if the user is nog logged on and the job needs access to the home folder. It might (or might not) also fail because the cronjob does not take over the session keys.

Example:

[evert@alfheim ~]$ keyctl list @s
3 keys in keyring:
778734583: --alswrv  1001 65534 keyring: _uid.1001
1053809321: --alsw-v  1001  1001 logon: ext4:743de876a7ff9436
156760729: --alsw-v  1001  1001 logon: ext4:95a45eb6e555fa2f

Cron <evert@alfheim>
1 key in keyring:
 58334521: ----s-rv     0     0 user: invocation_id

Note the logon: ext4 stuff missing in the cron session.

Sometimes it looks like the script kinda works because of the cache. More about that:

https://lkml.org/lkml/2016/9/14/364

I couldn't get cron to work reliably so I wrote a shellscript to have my periodic stuff executed while I'm logged on:

https://github.com/evert-mouw/session.sh

Suggestion: just mention these problems in the documentation / wiki / whatever. Of course there is no solution for it, but the problem is hard to debug and could hit others.

systemd --user instance doesn't inherit user's session keyring

Systemd --user instance which is started through pam_systemd.so module doesn't use user's session keyring so all user services don't have access to encrypted files. I already reported it upstream but it looks like a design choice which breaks many types of authentication. I don't know if pam_e4crypt could help with this linking keys from user keyring to systemd-user keyring or add keys to system-user keyring directly.

pam_e4crypt: Failed to retrieve key list!

I'm sorry to disturb you again but I can't get it working after installation and the Readme isn't very detailed.

I've set following in pam.d/system-auth:

auth      sufficient    pam_unix.so     try_first_pass nullok
auth      optional   pam_e4crypt.so
auth      optional  pam_permit.so
auth      required  pam_env.so

session    optional   pam_keyinit.so       force revoke debug
session    optional   pam_e4crypt.so
session   required  pam_limits.so
session   required  pam_unix.so
session   optional  pam_permit.so

And it doesn't add my ext4 keys after login. I have following error in syslog:
pam_e4crypt: Failed to retrieve key list!
what are the correct entries in pam.d?

nice work

This is not a real issue. I just wanted to say "thanks" because I'm making use of this module 👍
I encountered a few small problems. Some of my config files were not saved (XFCE4, Arch Linux), I could not unlock my session (LightDM) and so on. It might be correlated with the systemd login "features". Anyway I just activated all keyring methods (s, us, u) and it seems to work so far... I'll share my pam config:

/etc/pam.d/system-login

#%PAM-1.0

auth       required   pam_tally.so         onerr=succeed file=/var/log/faillog
auth       required   pam_shells.so
auth       requisite  pam_nologin.so
auth       include    system-auth
auth       required   pam_e4crypt.so       saltpath=/home/.e4crypt keyring=@s
auth       required   pam_e4crypt.so       saltpath=/home/.e4crypt keyring=@us
auth       required   pam_e4crypt.so       saltpath=/home/.e4crypt keyring=@u

account    required   pam_access.so
account    required   pam_nologin.so
account    include    system-auth

password   include    system-auth

session    optional   pam_loginuid.so
session    optional   pam_keyinit.so       force revoke
session    required   pam_e4crypt.so       saltpath=/home/.e4crypt keyring=@s
session    required   pam_e4crypt.so       saltpath=/home/.e4crypt keyring=@us
session    required   pam_e4crypt.so       saltpath=/home/.e4crypt keyring=@u
session    include    system-auth
session    optional   pam_motd.so          motd=/etc/motd
session    optional   pam_mail.so          dir=/var/spool/mail standard quiet
-session   optional   pam_systemd.so
session    required   pam_env.so

Implement password management function

We currently don't react on password changes performed by users. After an user changes his/her password, the files and directories previously encrypted are still encrypted with the old keys.

We should implement the corresponding PAM password management functions and document the issue for users.

[info] fscrypt by google

There is new fscrypt tool https://github.com/google/fscrypt with pending PR to add pam integration google/fscrypt#25 . It has drop_caches option which would solve #11 , see https://github.com/google/fscrypt/pull/25/files#diff-04c6e90faac2675aa89e2176d2eec7d8R194 and probably many more features suitable for pam_e4crypt

Userspace usage

A bit late since I've already submitted a PR and everything, but how do you handle the userspace side of this? I know I can e4crypt add_key -S $salt $dir to set up an encrypted folder, but this key doesn't end up enabled after login through pam_e4crypt.

Is there something else I need to be doing in userspace to get it to work?

Re-introduce support for EXT4_IOC_GET_ENCRYPTION_PWSALT and iterating over mtab

I am very curious why support for the EXT4_IOC_GET_ENCRYPTION_PWSALT ioctl() and the iteration routine over mtab was removed.

After reading some e2fsprogs and linux kernel source, it appears the idea of e4crypt is to store the salt in the superblock of the ext4 filesystem, in an effort to become more "user-friendly" (see tytso/e2fsprogs@41f2210). And this appears sensible to me. And while pam_e4crypt once had support for the EXT4_IOC_GET_ENCRYPTION_PWSALT ioctl() which returns the (per ext4 filesystem) salt, it was removed with #27. Furthermore, iterating over all filesystem entries in mtab was removed with #25.

I can not think of a good reason, especially since ext4 appears to be moving towards storing the salt in the filesystem superblock. And if pam_e4crypt would simply create a policiy (key+salt) for every ext4 filesystem in mtab, then the usage of pam_e4crypt would become much easier.

Slightly related side-node: pam_e4crypt's README currently stats that "Users must provide a salt (up to 16 bytes)". This is not entirely correct, e4crypt is able to handle salts of much larger sizes. Only the salt stored in the superblock and returned by the ioctl() is 16 bytes in size.

Would you accept patches that re-introduce EXT4_IOC_GET_ENCRYPTION_PWSALT and iterating over mtab?

Changing LIBDIR to /usr/lib

Hello, I'm trying build your module and I have to set install path as /usr/lib but it's falling to /usr/lib64 instead.
Here is relevant part from https://github.com/neithernut/pam_e4crypt/blob/e026ffe267b42f774a04358a9f55d7dd86d4ec80/CMakeLists.txt

# install the module in the same place where all the other modules should be
# NOTE: we actually disrespect the install prefix here
get_filename_component(LIBDIR ${PAM_LIBRARY} DIRECTORY)
install(TARGETS pam_e4crypt
LIBRARY DESTINATION "${LIBDIR}/security/

Could you guide me how to fix this?

Thank you for this great work!

Salt handling does not match `e4crypt add_key`

The key pam_e4crypt creates doesn't match the one created by e4crypt using the same salt.

As an example on a fresh VM:

j@debian:~$ keyctl show
Session Keyring
 839405059 --alswrv      0     0  keyring: _ses
 391939558 ----s-rv      0     0   \_ user: invocation_id
1068008579 --alsw-v   1000  1000   \_ logon: ext4:d10d0fa4d20bf12d
 272528715 --alsw-v   1000  1000   \_ logon: ext4:ed04c65c899cb4cf
j@debian:~$ e4crypt add_key -S `cat .ext4_encryption_salt`
Enter passphrase (echo disabled): 
Added key with descriptor [1c6e284e1169c44e]
j@debian:~$ cat .ext4_encryption_salt 
s:ac335322fe640688b17a41708517fc96
j@debian:~$ e4crypt add_key -S s:ac335322fe640688b17a41708517fc96
Enter passphrase (echo disabled): 
Key with descriptor [1c6e284e1169c44e] already exists

As you can see, something pam_e4crypt is doing doesn't fit with e4crypt since they generate different keys.

Reboot and log into a different user and attempt to decrypt, and you'll see it doesn't work.

Wipe potential secrets off memory

We use buffers to calculate/store keys. Those buffers are not zeroed before being free()d/brefore they scope out. This is a security risk.

Make a man page

PAM modules usually come with a manual.

Packaged for distros

It would be great if this was in the debian repos - it should be possible to automatically add to PAM too since the ecryptfs-utils package does the same

Keys not flushed from cache after logout

There is known issue that keys aren't cleared from inode cache automatically after user session is closed. See here

Other issues include the filesystem cache that is not invalidated when the key is unlinked and still lets you see the plaintext filenames.

and here (same author)

Plaintext filenames still appear after detaching the key

That is a kernel issue. The dentries cache is not invalidated when you remove the key and still contains the plaintext filenames.

You must remount the device or force a filesystem cache flush with:

# echo 2 > /proc/sys/vm/drop_caches

During my tests it not only shows filenames as plaintext but their context too. You can see all keys in /proc/keys directory. keyctl show command display only keys set from current session.

Actual remedy for this is executing # sync && echo 2 > /proc/sys/vm/drop_caches command as described above. It may need executing as sync && echo 2 | sudo tee /proc/sys/vm/drop_caches in case of insufficient permissions. See here for avalaible documentation. According to this executing this command is only an one-off and hasn't any further consequences for running system.

The only question is, does pam_e4crypt has capability to taking care of this (flushing caches after session close) or some external tools have to be involved?

Is the 16-byte salt length required ?

I used a custom salt that was not a fixed 16 bytes length and it still worked. Also in the code I see nowhere where there is a hard check for the 16-byte length, is there a reason for keeping this detail on the README ?

PAM failed: Cannot make/remove an entry for the specified session

Some part of the PAM open-session step fails on my system if (and only if) I enable pam_e4crypt.
The weird part is that the error occurs before pam_e4crypt is executed.

Good session start
No session [...] pam_e4crypt.so was enabled.
journalctl:

Jan 08 21:44:54 hostname login[464]: pam_e4crypt: Generating key with salt length 34 from file '/.ext4-salts/samuel'
Jan 08 21:44:54 hostname login[464]: pam_unix(login:session): session opened for user samuel by LOGIN(uid=0)
Jan 08 21:44:54 hostname systemd[1]: Created slice User Slice of samuel.
Jan 08 21:44:54 hostname systemd[1]: Starting User Manager for UID 1000...
Jan 08 21:44:54 hostname systemd-logind[447]: New session c1 of user samuel.
Jan 08 21:44:54 hostname systemd[1]: Started Session c1 of user samuel.
Jan 08 21:44:54 hostname systemd[797]: pam_unix(systemd-user:session): session opened for user samuel by (uid=0)
Jan 08 21:44:54 hostname systemd[797]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Jan 08 21:44:54 hostname systemd[797]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Jan 08 21:44:54 hostname login[464]: LOGIN ON tty1 BY samuel
Jan 08 21:44:54 hostname systemd[797]: Reached target Timers.
Jan 08 21:44:54 hostname systemd[797]: Listening on Sound System.
Jan 08 21:44:54 hostname systemd[797]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Jan 08 21:44:54 hostname systemd[797]: Reached target Paths.
Jan 08 21:44:54 hostname systemd[797]: Starting D-Bus User Message Bus Socket.
Jan 08 21:44:54 hostname systemd[797]: Listening on GnuPG cryptographic agent and passphrase cache.
Jan 08 21:44:54 hostname systemd[797]: Listening on GnuPG network certificate management daemon.
Jan 08 21:44:54 hostname systemd[797]: Listening on D-Bus User Message Bus Socket.
Jan 08 21:44:54 hostname systemd[797]: Reached target Sockets.
Jan 08 21:44:54 hostname systemd[797]: Reached target Basic System.
Jan 08 21:44:54 hostname systemd[797]: Reached target Default.
Jan 08 21:44:54 hostname systemd[797]: Startup finished in 23ms.
Jan 08 21:44:54 hostname systemd[1]: Started User Manager for UID 1000.

Bad session start
session required pam_e4crypt.so debug was appended to the end of /etc/pam.d/system-login (I know the debug option has no effect).
journalctl:

Jan 08 21:54:31 hostname login[458]: pam_e4crypt: Generating key with salt length 34 from file '/.ext4-salts/samuel'
Jan 08 21:54:31 hostname login[458]: pam_unix(login:session): session opened for user samuel by LOGIN(uid=0)
Jan 08 21:54:31 hostname systemd[1]: Created slice User Slice of samuel.
Jan 08 21:54:31 hostname systemd[1]: Starting User Manager for UID 1000...
Jan 08 21:54:31 hostname systemd-logind[440]: New session c1 of user samuel.
Jan 08 21:54:31 hostname systemd[1]: Started Session c1 of user samuel.
Jan 08 21:54:31 hostname systemd[801]: pam_unix(systemd-user:session): session opened for user samuel by (uid=0)
Jan 08 21:54:31 hostname systemd[801]: PAM failed: Cannot make/remove an entry for the specified session
Jan 08 21:54:31 hostname systemd[801]: [email protected]: Failed to set up PAM session: Operation not permitted
Jan 08 21:54:31 hostname systemd[801]: [email protected]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not pe$
Jan 08 21:54:31 hostname systemd[1]: [email protected]: Failed with result 'protocol'.
Jan 08 21:54:31 hostname systemd[1]: Failed to start User Manager for UID 1000.
Jan 08 21:54:31 hostname login[458]: pam_systemd(login:session): Failed to create session: Start job for unit [email protected] $
Jan 08 21:54:31 hostname login[458]: pam_e4crypt: Unknown option for open_session: debug
Jan 08 21:54:31 hostname login[458]: pam_e4crypt: Inserting key with reference ext4:1661114a43da0fbf as 1000:1000
Jan 08 21:54:31 hostname login[458]: LOGIN ON tty1 BY samuel

Both tests were done immediately after a fresh reboot.

The end effect of this is that the user services don't start.

Any ideas why this might happen? Has anyone seen this before?
A Google search turned this up, but the main thing I learned from that is that PAM's error message is useless.
Does PAM load all modules up front and then just call the pam_sm_open_session functions in order?

Build test executable

... to ensure we linked agains all the things we are using. I believe CMake already supports this, but I have forgotton what I have to do to activate this.

Failure to transport keys from auth to session stage with pam-1.4.0

After upgrading PAM on one of my machines pam_e4crypt ceased working: apparently, the retrieval of policies in the session stage fails. I'll have to investigate whether this is a general problem or whether its just some quirk with my setup (pretty much the standard Gentoo setup with elogind rather than systemd). I didn't find anything suspicious in the release notes, at least.

On the up-side, pam-1.4.0 introduces an API for providing an alternative config directory, which enables some testing setups which were not possible, previously.

Add ext2fs package to cmake dependencies

sshd support

Hello!
It will be nice if your very useful module got ssh support :)

This is the plain local login
Mar 1 18:45:56 fluffy login[20716]: pam_e4crypt: Generating key with salt length 16 from file '/etc/pam.d/fox'
Mar 1 18:45:56 fluffy login[20716]: pam_e4crypt: Inserting key with reference ext4:826f76abc8542ebc as 1000:10
Mar 1 18:45:56 fluffy login[20716]: pam_unix(login:session): session opened for user fox(uid=1000) by LOGIN(uid=0)

And this is the login log via ssh
Mar 1 18:45:37 fluffy sshd[20765]: pam_e4crypt: Generating key with salt length 16 from file '/etc/pam.d/fox'
Mar 1 18:45:37 fluffy sshd[20762]: Accepted keyboard-interactive/pam for fox from 10.10.10.4 port 52155 ssh2
Mar 1 18:45:37 fluffy sshd[20762]: pam_e4crypt: Failed to retrieve key list!

As i see, ssh key insertion doesn't happens in the via ssh login case...

Adhere to XDG spec

Would be better to follow https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html for salt (and all other) files:
Use $XDG_CONFIG_HOME/ext4_encryption_salt instead of $HOME/.ext4_encryption_salt