| Title: Linux $HOME encryption with ecryptfs
Author: Solène
Date: 12 March 2023
Tags: linux encryption privacy
Description: In this article, you will learn how to encrypt a user home
directory, or a single directory using ecryptfs
# Introduction
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
|
|
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.
# Private directory encryption
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.
## Setup
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!
# Performance
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.
# Security shortcoming
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.
# Troubleshooting
## setreuid: Operation not permitted
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.
# Conclusion
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. |