mike@xxxxxxxx wrote: >Have you seen pam_mount? It is available at http://www.flyn.org and one of its >specialties is mounting encrypted home directories. Yes, I've seen pam_mount; although it's not a strict superset of the capabilities of pam_losetup, it has significantly more functionality. My aim with pam_losetup was to keep it very minimalist, and focus on retrieving keys, hashing and setting up encrypted loops. > In fact, if you can find an >August issue of the Linux Journal, you will find an article on this very subject >(though it addresses Linux 2.4's cryptoloop). Actually, pam_losetup also addresses 2.4's cryptoloop, but the changes to accomodate 2.6 should be minimal (a few /dev path names and perhaps changes in losetup invocation). Sorry for not making this clear. > Pam_mount also allows one to change their system password without changing their >encrypted filesystem's key (which can easily be truly random/maximum entropy >because the user does not need to remember it). Exactly the same idea in pam_losetup; I derive the filesystem key from /dev/random before encrypting it. I also added a salt to the passphrase hash to foil dictionary attacks on the passphrase. I'm currently using md5crypt to derive 128 bits for the internal des_ede operation to encrypt/ decrypt the filesystem key (it's probably sufficient to use DES, since the entropy of the unencrypted filesystem key is maximal). The main pros of pam_losetup are: 1) The addition of the system keyfile, /etc/qpasswd greatly reduces the clutter/overload in /etc/fstab. The options field was getting cluttered with all the 'cipher=' and 'keybits=' stuff, which is all now relocated to /etc/ qpasswd. The format of an entry in /etc/qpasswd is simple and minimal: <login_name>:<loopdev_index>:<loop_container>:<cipher>:<keysize>:<salt>:<key > Both the salt and key are base64 encoded, so it's possible to keep the line below 80 chars (I like my text files to fit without line-wrap :-). I've included a simple library to manipulate keyfiles, with the routines fgetqpent(), getqpent(), setqpent(), endqpent() & putqpent(). The semantics are similar if not identical to the passwd file handling routines in glibc - fgetpwent(), ... . 2) Focus on key management: all the user (filesystem) keys are kept together, so interesting things can be done with them (key backup, escrow, etc.). Also, the keyfile can be kept on removable media, for more security. 3) mount has a much simpler task - it can look at a more classical, uncluttered, /etc/fstab, which will have simple entry linking the loop device and the home directory (or any other directory, for that matter). 4) It's still possible to use pam_mount in the PAM stack following pam_losetup, for example: ... auth required /lib/security/pam_losetup.so ... session required /lib/security/pam_losetup.so ... auth required /lib/secuirty/pam_mount.so ... session required /lib/security/pam_mount.so ... ... For certain applications (like login), pam_losetup plus a redirection login script in a dummy home directory, seems to be sufficient. Cons: 1) Nested encrypted loops, possible with pam_mount, are not possible with pam_losetup, although multiple encrypted loops, with directory nesting, are still possible (it's not possible to keep the container file within another encrypted filesystem, which is not that much of a downside). Possible future directions include a merge of the codebases of pam_losetup and pam_mount, though it seems not to be necessary in the light of 4) above. I'm pretty pleased with my introduction of the concept of keyfiles, so I'd like to keep that in pam_losetup. I think a simple pam_losetup, which handles keys and loop setup, and a simple pam_mount, which handles mounts only, might be a good general direction to head. Comments, suggestions, etc. welcome. -Siva schander@xxxxxxxxxxxxxx Qryptix Data Security, Chennai, India. -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
