Comments on Creating A Safe Directory With PAM And EncFS

This is a great howto, thanks.

But it misses one important information, which is what happens when the user changes his password. As the login password is used to decrypt the encfs files, it will no more possible to decrypt them at the next login.

To avoid that, we should use encfsctl, which is provided with encfs, to reencrypt the files with the new password. This can not be done with pam_script without modifying it to manage event like onpasswdchange for example, but we can rename the binary passwd in passwd.bin and add a new shell passwd which will ask twice the password, call passwd.bin to update the user password and if the last call succeed, call encfsctl to reencrypt the files as well as update the reference to the password file password.tmp.

Sorry, I forgot some things.

First of all, thank you for the compliment.

Very important to know, I've meant this safe only for security during a session (and an occasional crash), After a session it can be destroyed (read: cleaned, unmounted and removed). Because it purpose it to store only information like passwords, (and maybe krb5 tickets?????) , nothing else!!

So there is no reason to keep the encrypted between two logins and try to open it again with (the changed) credentials. My idea is to create a brand new safe directory, every login again. And no encrypted file of directory needs te be kept untill the next login.

So, every login a brand new safe can be created, any old one may be forgotten (removed).

Stef Bon

Given that you explicitly don't want the safe to survive a reboot, is there any reason to use a persistent filesystem at all? The advantage of EncFS is that the files continue to exist after a reboot; a tmpfs would work for your session system.

The only disadvantage of a tmpfs is that if your swap isn't encrypted, your session data isn't encrypted if it's swapped out; this is already a risk if the programs you're using the session data with aren't carefully written to lock the data into memory. In any case, if you're worried about what could happen if I hit your machine with a LiveCD, you're already encrypting swap.

Thanks for the suggestion, I haven't been thinking of this. I understand that this is making things easier. How can I achieve this? Just create a tmpfs by mounting? And what about encryption? Can I use encfs on top off tmpfs? Stef

You're absolutely right. When a user in a session changes his/her password, the key to the encrypted directory is not valid anymore. But I would like to make some remarks about this issue:

1. I've chosen the password as key, but this isn't necessary. Any unique key will do! When I look around there are more systems creating unique keys to identify sessions with. I know these keys are used, but I do not have enough knowledge how this works. Examples of these (of which I think are good) are FreeNX (the server creates a unique id for a user session). Maybe a PHP session is also a good example. According to me these sessions are also identified with a unique session id.
   
2. The purpose of a key is because Encfs needs one! It has nothing to do with the security I'm using it for. I'm using it to ensure that files containing sensitive information like passwords can not be read when a these files accidently remain on the harddrive (a crash fe). If this could be done without a key: great. Maybe I'm saying something stupid here, maybe this key is really necessary to enforce unique encryption I don't know.