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.

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.