-- Leo's gemini proxy
-- Connecting to perso.pw:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;
Author: Solène
Date: 12 March 2023
Tags: linux encryption privacy
In this article, I'd like to share with you about the Linux specific feature ecryptfs, which allows users to have encrypted directories.
While disk encryption done with cryptsetup/LUKS is very performant and secure, there are some edge cases in which you may want to use ecryptfs, whether the disk is LUKS encrypted or not.
I've been able to identify a few use cases making ecryptfs relevant:
a multi-user system, people want their files to be private (and full disk encryption wouldn't help here)
an encrypted disk on which you want to have an encrypted directory that is only available when needed (preventing a hacked live computer to leak important files)
a non-encrypted disk on which you want to have an encrypted directory/$HOME instead of reinstalling with full disk encryption
In this configuration, you want all the files in the $HOME directory of your user to be encrypted. This works well and especially as it integrates with PAM (the "login manager" in Linux) so it unlocks the files upon login.
I tried the following setup on Gentoo Linux, the setup is quite standard for any Linux distribution packaging ecryptfs-utils.
As I don't want to duplicate documentation effort, let me share two links explaining how to set up the home encryption for a user.
Both guides are good, they will explain thoroughly how to set up ecryptfs for a user.
However, here is a TLDR version:
1. install ecryptfs-utils and make sure ecryptfs module is loaded at boot
2. modify `/etc/pam.d/system-auth` to add ecryptfs unlocking at login (3 lines are needed, at specific places)
3. run `ecryptfs-migrate-home -u $YOUR_USER` as root to convert the user home directory into an encrypted version
4. delete the old unencrypted home which should be named after `/home/YOUR_USER.xxxxx` where xxxxx are random characters (make sure you have backups)
After those steps, you should be able to log in with your user, `mount` outputs should show a dedicated entry for the home directory.
In this configuration, you will have ecryptfs encrypting a single directory named `Private` in the home directory.
That can be useful if you already have an encrypted disk, but you have very secret files that must be encrypted when you don't need them, this will protect file leak on a compromised running system, except if you unlock the directory while the system is compromised.
This can also be used on a thrashable system (like my netbook) that isn't encrypted, but I may want to save a few files there that are private.
That part is really easy:
1. install a package named `ecryptfs-utils` (may depend on your distribution)
2. run `ecryptfs-setup-private --noautomount`
3. Type your login password
4. Press enter to use an auto generated mount passphrase (you don't use this one to unlock the directory)
5. Done!
The mount passphrase is used in addition to the login passphrase to encrypt the files, you may need it if you have to unlock backuped encrypted files, so better save it in your password manager if you make backup of the encrypted files.
You can unlock the access to the directory `~/Private` by typing `ecryptfs-mount-private` and type your login password. Congratulations, now you have a local safe for your files!
Ecryptfs was available in older Ubuntu installer releases as an option to encrypt a user home directory without the full disk, it seems it has been abandoned due to performance reasons.
I didn't make extensive benchmarks here, but I compared the writing speed of random characters into a file on an unencrypted ext4 partition, and the ecryptfs private directory on the same disk. On the unencrypted directory, it was writing at 535 MB/s while on the ecryptfs it was only writing at 358 MB/s, that's almost 33% slower. However, it's still fast enough for a daily workstation. I didn't measure the time to read or browse many files, but it must be slower. A LUKS encrypted disk should only have a performance penalty of a few percent, so ecryptfs is really not efficient in comparison, but it's still fast enough if you don't do database operation on it.
There are extra security shortcomings coming with ecryptfs: when using your encrypted files unlocked, they may be copied in swap or in temporary directories, or in cache.
If you use the Private encrypted directories, for instance, you should think that most image reader will create a thumbnail in your HOME directory, so pictures in Private may have a local copy that is available outside the encrypted directory. Some text editors may cache a backup file in another directory.
If your system is running a bit out of memory, data may be written to the swap file, if it's not encrypted then one may be able to recover files that were opened during that time. There is a command `ecryptfs-setup-swap` from the ecryptfs package which check if the swap files are encrypted, and if not, propose to encrypt them using LUKS.
One major source of leakage is the `/tmp/` directory, that may be used by programs to make a temporary copy of an opened file. It may be safe to just use a `tmpfs` filesystem for it.
Finally, if you only have a Private directory encrypted, don't forget that if you use a file browser to delete a file, it may end up in a trash directory on the unencrypted filesystem.
If you get the error `setreuid: Operation not permitted` when running ecryptfs commands, this mean the ecryptfs binaries aren't using suid bit. On Gentoo, you have to compile `ecryptfs-utils` with the USE suid.
Ecryptfs is can be useful in some real life scenarios, and doesn't have much alternative. It's especially user-friendly when used to encrypt the whole home because users don't even have to know about it.
Of course, for a private encrypted directory, the most tech-savvy can just create a big raw file and format it in LUKS, and mount it on need, but this mean you will have to manage the disk file as a separate partition with its own size, and scripts to mount/umount the volume, while ecryptfs offers an easy secure alternative with a performance drawback.
-- Response ended
-- Page fetched on Mon May 6 05:52:34 2024