Auto-mounting LUKS container as encrypted home directory.

[xennex81]

In order to get an encrypted home directory based on an encrypted file container mounted as a block device onto your home directory.

Based on the topic by oshunluvr that dealt with auto-mounting certain volumes for users upon login based on a bind mount so as to get these volumes accessible through the home directory.....

The answer by SteveRiley pointed to this documentation: https://wiki.archlinux.org/index.php/pam_mount

The goal is to replace eCryptfs, which encrypts individual files, with a LUKS or TrueCrypt container (encrypting the subtree as a whole) for the home directory of (every) user (excepting root).

Steve pointed out that libpam-mount is capable of mounting volumes for a user session.


Here is a recipe that will work with a dm-crypt (LUKS) container:

(Run everything as root.)

1. Install libpam-mount:

apt-get install libpam-mount

2. For each user, create a LUKS container using: (actually, you need the user's password for that)...

user=<name>
mkdir /home/$user/.luks/
pmt-edh -f /home/$user/.luks/$user.cont
chown $user.$user /home/$user/.luks/$user.cont

3. Make sure the root of that container is owned by the user:

mount /home/$user/.luks/$user.cont /home/$user
chown $user.$user /home/$user
umount /home/$user

4. Just mount it somewhere else so you can copy the home directory into it. Umount it again.

Repeat for other users.

5. Add to that file /etc/security/pam_mount.conf.xml:

<lclmount>mount -t%(FSTYPE) %(VOLUME) %(MNTPT) "%(if %(OPTIONS),-o%(OPTIONS))"</lclmount>
<volume fstype="crypt" path="/home/%(USER)/.luks/%(USER).cont" mountpoint="/home/%(USER)" options="fsck,noatime" />

6. Presto

• The password for the container must be the same as the password for the user login
• It will mount and unmount on console login and console su, but it will not unmount after you have had a (Lightdm) session.
• It will do this for every user that tries to login.
• It will mount the container on top of the home dir, but (usually) before you enter that directory, which means you get the 'fresh' view (which is the contents of the container)
• It will (the way it is now) also try to do it for root, but root has no /home/root ;-).
• You can change the line <volume .... to the archwiki line (or the one presented by pmt-ehd when it finishes creating the thing) which means you can make one line for every user with <volume user="xxx" ......................... /> so that each user is individually selected instead of all
• You could create a separate mount script that can be a little more intelligent, and that could also (?) transfer into mounting a truecrypt container instead.
• Apparently it passes the password onto the LUKS using the ...stdin, I presume. Since that works perfectly. (You can just pipe the password to mount)
• Why then not just use "truecrypt -k "" --protect-hidden=no %(VOLUME) %(MNTPT)" instead?
• The mount will hide the encrypted container from view, to unmount simply "umount" your home directory.
• ...
• It will ocassionally "fail" to dismount upon logout which may cause it to "fail" upon login again, but another logout will then fix that.

[xennex81]

I'm thinking also of just using some keyfile instead of a passphrase. It would be less secure (root can access your keyfile) but a bit safer (as long as you have the keyfile you are okay) and changing a user password would not require changing the passphrase of the container.

The container that pmt-ehd creates is just a luks container:

# cryptsetup isLuks <testfile.cont>
# echo $?
0

Returns true. You can change the password using:

cryptsetup luksChangeKey <file.cont>

You can backup the header using:

cryptsetup luksHeaderBackup <file.cont> --header-backup-file <backup>

..and so on. But that can make a password less secure: header+password is enough to decrypt, even if the password was later changed (which changes the header).

Seems to me like a pretty decent approach. You could keep the key if you have a key file (or just a keyfile) loaded on some USB stick for backup, and encrypt that with a simple ccrypt or aescrypt. The keyfile would reside in your home directory and be user readable, but no one else (except root) and it would be hidden by the mounted volume. The keyfile could even be encrypted with e.g. ccrypt with a two-way cipher (symmetric) such that your user password is then used to decrypt the keyfile which is used to decrypt the home directory and so on lol lol lol ;p.

The advantage of using a block file container is obviously that you can keep hidden volumes in there as well. For example... you can make the hidden volume decryptable with your password, and you let a keyfile 'hang around' that only decrypts the outer volume. Given sufficient PAMmability you can then have two user passwords that both log you in, and one logs you in with the hidden, and the other logs you in with the exposed. Easy peasy.

It's a pain though to use them both; ie. to use both the hidden and the exposed one. You regularly have to take care to fill the exposed volume with garbage or unwanted files, or files that draw attention but not nearly the kind that would you consider to be harmful to you in a real way.