Document home directory encryption for Ubuntu/Debian and Fedora

[cs224]

As ubuntu dropped the support for home directory encryption I am trying to do it myself via fscrypt in ubuntu 18.04 bionic. I am doing my experiments first via virtualbox before I dare to do it on a real machine. I am following the the description here: http://tlbdk.github.io/ubuntu/2018/10/22/fscrypt.html I get it working, but not easily or smoothly. I run into different problems that I can work around. The whole process feels quite "hacky".

Is there a place where I can find tutorials for how to get home directory encryption working in different distros via fscrypt? And if not, could one of the experts please create such tutorials?

Searches via google show that the whole info-space around fscrypt is still very sparse.

Thanks a lot! Christian

[josephlr]

Hey @cs224 thanks for opening this. Getting better documentation is definitly on my radar, and will be a requirement for releasing 1.0, the API is expected to change a little, so I didn't want to write up a whole long thing, just for it to be out of date.

If anyone has suggestions for other distros where separate documentation sections would be needed, mention them here.

[cs224]

Just to have said it: I managed to set-up home directory encryption via the documented process from above on the "real machine" and so far it works fine.

The only thing I noticed that has some issues is ssh remote access via key authentication, even after having logged in with the user to whom the home directory belongs.

What I do. I go from machine A to machine B via ssh. Machine B has a user "sec", who has set-up home directory encryption. I login the first time via password so that the directory gets unlocked. After that I have to go to the .ssh directory and open the authorized_keys file via for example "less" to make key authentication working. It then works for quite some time. But after some time it stops working and I have to do the same again, e.g. go again to .ssh and open the authorized_keys file. It feels as if the file authorized_keys gets into some cache by opening it and after some time it gets evicted from that cache and then the key authentication stops working.

I am not 100% sure that the problem is due to my home directory encryption set-up, but I only observed this behaviour so far with the "sec" user. I have other users on that machine that do not use home directory encryption, but I use them less, e.g. am not 100% sure that the problem only exists for the "sec" user.

[ebiggers]

What I do. I go from machine A to machine B via ssh. Machine B has a user "sec", who has set-up home directory encryption. I login the first time via password so that the directory gets unlocked. After that I have to go to the .ssh directory and open the authorized_keys file via for example "less" to make key authentication working. It then works for quite some time. But after some time it stops working and I have to do the same again, e.g. go again to .ssh and open the authorized_keys file. It feels as if the file authorized_keys gets into some cache by opening it and after some time it gets evicted from that cache and then the key authentication stops working.

This is a known issue with filesystem encryption in the kernel: the caches that allow encrypted files to be accessed are systemwide, whereas the encryption keyrings are per-user. Thus, there can be inconsistent behavior when a process doesn't "have" the key but the files were recently accessed by a process which does. I have a plan to address this by having the encryption keyring be associated with the filesystem, rather than particular users. At the moment I'm busy with other work, but feel free to make some noise (e.g. on linux-fscrypt mailing list) if you'd like to see this fixed :-)

FWIW, in the ssh case, this can be worked around by keeping authorized_keys open all the time.

[martin9959]

Maybe this also explains the problem that I have reported here. I imagine that there might be many other cases where files within the home directory are acessed by root?

[cs224]

One other issue I noticed is the kwallet, that does not get automatically unlocked after login. If I unlock the drive first and then login it works.

[ghost]

Is the linked patch still an RFC or was it merged upstream already?

[Redsandro]

@ebiggers said:

I have a plan to address this by having the encryption keyring be associated with the filesystem, rather than particular users. At the moment I'm busy with other work, but feel free to make some noise (e.g. on linux-fscrypt mailing list) if you'd like to see this fixed :-)

Any new developments regarding this issue?

#132 is a bit scary to me.

[ebiggers]

My kernel patchset to improve fscrypt key management hasn't been merged yet. Currently other kernel filesystem features are higher priority.

However, it will not solve #132. The solution to #132 is simply to chmod 0700 your encrypted directories.

[Redsandro]

I apologize, I misunderstood the impact of this patch.

[ebiggers]

I created a page on the Arch Linux wiki about fscrypt, including how to encrypt a home directory: https://wiki.archlinux.org/index.php/Fscrypt

The only part that really differs between the distros is the PAM configuration.

Regarding the discussion above about the encryption key access problems: the kernel patches needed to fix it were merged upstream for 5.4, and I have a pull request open for the userspace side of the fix.

[Redsandro]

Thank you. Looking forward to Linux 5.4.

I am a bit worried about the upgrade process though. It sounds simple enough, but before undertaking an upgrade of a system that already required the keyinit-fix workaround, I'd prefer to be double sure about the process in the hopes of not being locked out of my home after the upgrade.

Also, I am curious about how this would work when upgrading the system to the next major version (i.e. Ubuntu 20.04 LTS). I'm hoping that fscrypt will be implemented in the installer. Everyone please go to that issue and click on "this bug affects me too" to create heat.

[ebiggers]

If you have enough free disk space for a copy of your home directory alongside the original, the best thing to do (assuming it's okay for your directory to only be usable on Linux v5.4+) will be to create a copy of your home directory that uses a v2 encryption policy. Then verify it's being automatically unlocked before you replace your original home directory with it.

Alternatively, my pull request also makes it possible to opt-in to using the filesystem keyring for directories that use v1 encryption policies. So if you don't want to upgrade your directory to v2 right away, you'll also be able to switch to the filesystem keyring by changing /etc/fscrypt.conf, and if it causes a problem, simply undo the change to /etc/fscrypt.conf.

[Redsandro]

@ebiggers commented:

the best thing to do will be to create a copy of your home directory that uses a v2 encryption policy.

Is the encryption policy tied to a name, or a directory inode?

E.g. if I do this:

mv /home/redsandro{,-bup}
mkdir /home/redsandro

Does the new /home/redsandro take over old /home/redsandro's encryption policy, or does it move with the name change to /home/redsandro-bup?

Is the following a valid line of thought, assuming the old /home/redsandro is v1 fscrypted?

# rename v1 fscrypted home dir
mv /home/redsandro{,-bup}

# create new unencrypted home
mkdir /home/redsandro

# Setup v2 fscrypt
fscrypt encrypt /home/redsandro

# Transfer files
rsync -va --info=progress2 --info=name0 /home/redsandro{-bup,}/

# When you are 100% sure everything is copied and you can successfully log in,
# remove the old home.
rm -rf /home/redsandro-bup

[ebiggers]

The encryption policy is tied to the directory inode, so yes that will be the general process to migrate to a v2 policy --- it's what I meant by "create a copy of your home directory that uses a v2 encryption policy".

But it will need to be fscrypt encrypt, not fscrypt setup, and the rsync command needs a trailing slash on the source directory. Also, as long as you're making a full copy of the directory, you might as well verify that the new directory is working before actually moving or deleting the old one.

Check what I wrote for "Encrypt a home directory" on the Arch Linux wiki. It doesn't mention anything about v2 policies yet, but it will be the same process.

[Redsandro]

@ebiggers thanks for the heads up. I've updated my previous comment in case anyone finds/tries it without reading your message.

I know it might come across as slightly ignorant to ask if I'm having the right idea after you just said "create a copy of your home directory that uses a v2 encryption policy", but I'm sure you've can appreciate making sure what you mean is equal to what I think you mean, especially when a home dir is at stake. :cowboy_hat_face:

[Redsandro]

Warning: If a user's home directory is encrypted, ssh'ing to that user will not work until their home directory has been unlocked.

Since ssh is such a non-trivial tool, it might be worth mentioning a workaround after encrypting.

E.g.

1. Change /etc/ssh/sshd_config entry AuthorizedKeysFile to /home/.ssh/%u
2. sudo mkdir /home/.ssh
3. sudo mv /home/$USER/.ssh/authorized_keys /home/.ssh/$USER
4. ln -s /home/.ssh/$USER /home/$USER/.ssh/authorized_keys.

[zabbal]

Since ssh is such a non-trivial tool, it might be worth mentioning a workaround after encrypting.

This isn't a workaround - it's a security hole which completely defeats the purpose of using fscrypt in a first place. The only way it should be mentioned is with big red warning saying "never, ever do this".

[Redsandro]

Completely?

Disagree. Disable passwords of course. If you're smart enough to use arch linux, you'll know ed25519.

[zabbal]

Disagree. Disable passwords of course. If you're smart enough to use arch linux, you'll know ed25519.

Huh? What does passwords or ECC have to do with this? Do you even understand what fscrypt does?

[Redsandro]

Do you even understand what fscrypt does?

I would like to discuss this further, but not with you. This repo needs a code of conduct.

[zabbal]

This repo needs a code of conduct.

Which should absolutely forbid giving public security advice which might put users in danger.

[srd424]

Looks to me like it's a trade-off : leave ssh keys unprotected by fscrypt (remember they're already encrypted with passphrase) and login with key, or encrypt ssh keys, which requires allowing ssh login with password..?

[zabbal]

remember they're already encrypted with passphrase

What exactly makes you think that? Remember, we're talking about "authorized_keys" file for SSH.

This isn't a trade-off. You either protect highly sensitive data which allows complete remote access to the system or you don't bother. If latter is the case (which is perfectly legitimate) than there's no point bothering with fscrypt in a first place.

What we should really strive to avoid is giving user false sense of fake "security" - regardless whether we call it "workaround" or smth else.

[srd424]

Proposal above was to move all of .ssh.

authorized_keys is a list of public key fingerprints. Biggest risk presumably is someone else modifying it. Which clearly is a risk, but so is having to enable password authentication if authorized_keys is unavailable?

[Redsandro]

In hindsight I agree that it is a bad idea to suggest this type of .ssh workaround to groups of people.

There are cases for it though. I sometimes carry my ~ (it's on an external drive) between offices, and I want to protect against hardware theft. However I recently discovered that the other machine doesn't unlock the directory, and I am unsure how to set up encryption on that machine without breaking the encryption. It's easier to use a data-only portable drive, but I like to carry my settings. Either way, this is an unusual case.

On a laptop though, containing both ~ and authorized_keys, it will stop most hardware thieves (Windows script kiddies) who want to joy-ride your data before wiping your system and selling your laptop, but not all thieves (Linux users who know what to do). This is a (poor) trade-off between ease of use and security though, and while phoning your roommate at home from the office to ask if they turn on your laptop is a great trick in case of emergency, it, too, is an unusual case.

I'm wondering if another method exists to login externally when you did a remote WOL.

[flixman]

Hi everybody! I am trying to set up (Debian 10.6) the automatic home creation, encrypted, for any new user... and I am facing difficulties due to the documentation. So far, this is what I have:

# append PAM modules
pam-auth-update --package fscrypt

# create the decrypt-homedir script, set the executable bit at the end
cat <<EOF >/sbin/decrypt-homedir

#!/bin/bash

set -eu

PASS=$(cat /dev/stdin)

if [ ! -d /home/$PAM_USER ]; then mkdir -m 755 /home/$PAM_USER chown $PAM_USER:$PAM_USER /home/$PAM_USER echo $PASS | fscrypt encrypt /home/$PAM_USER --user=$PAM_USER --source=pam_passphrase cp -r /etc/skel/. /home/$PAM_USER/ chown -R $PAM_USER:$PAM_USER /home/$PAM_USER fi exit 0 EOF chmod a+x /sbin/decrypt-homedir

# set pam to decrypt the home folder on a successful login
echo "auth required pam_exec.so expose_authtok debug log=/tmp/file.log /sbin/decrypt-homedir" >> /etc/pam.d/common-account

Can anybody assess if this is a correct line of thought?

[mikunimaru]

Hi everybody! I am trying to set up (Debian 10.6) the automatic home creation, encrypted, for any new user... and I am facing difficulties due to the documentation. So far, this is what I have:

# append PAM modules
pam-auth-update --package fscrypt

# create the decrypt-homedir script, set the executable bit at the end
cat <<EOF >/sbin/decrypt-homedir

#!/bin/bash

set -eu

PASS=$(cat /dev/stdin)

if [ ! -d /home/$PAM_USER ]; then mkdir -m 755 /home/$PAM_USER chown $PAM_USER:$PAM_USER /home/$PAM_USER echo $PASS | fscrypt encrypt /home/$PAM_USER --user=$PAM_USER --source=pam_passphrase cp -r /etc/skel/. /home/$PAM_USER/ chown -R $PAM_USER:$PAM_USER /home/$PAM_USER fi exit 0 EOF chmod a+x /sbin/decrypt-homedir

# set pam to decrypt the home folder on a successful login
echo "auth required pam_exec.so expose_authtok debug log=/tmp/file.log /sbin/decrypt-homedir" >> /etc/pam.d/common-account

Can anybody assess if this is a correct line of thought?

The current Debian is set up simply by installing libpam-fscrypt and fscrypt. No file editing by user is required.