I fixed systemd-homed!

Last updated: February 25, 2020

Guys, I just did it! I fucking did it!!! I fixed systemd-homed's issues!!!

Earlier one of my friends told me about how they store all their data on their laptop and they carry it all along in their backpack. Fine, right. I mean, why would you store it somewhere else. But basically the guy wanted more or less what systemd-homed would do but he used full disk encryption for it. Which.. as Poettering so eloquently put it, is completely useless if your laptop is suspended in your backpack as the keys remain in memory. Fair point. I honestly don't do full disk encryption for pretty much the same reason and not caring quite as much about encryption of my programs as I do about their integrity. What I care about in "the rest of my system that is not my home directory" is rootkits. Something that would want to tamper with my programs in a way that I wouldn't be able to find out about it.

Digitally signed programs (which GnuPG could do with its detached signatures) would for that reason be an amazing idea. And every time you run the program, you could verify that signature first. If there's a perceivable performance impact with that, there's a variety of intermediary ways that could be used to verify with the GPG signature just as a "root certificate" if you so will. Like hashing the program and comparing against an also digitally signed hash table and only doing the GPG verification itself if that differs or something like that. Until that happens, rkhunter usually does the job reasonably well. But I digress.

When we talk about encrypted home directories, what are we really talking about? Encrypting your personal data. Not your dotfiles or whatever, but rather your documents, pictures, things like that. So let's encrypt those instead and not bother with all those dotfiles that programs just had to use. With that said and for the sake of completeness, I'd like to quickly go over why dotfiles reside in the home directory as well.. so that we kind of know why they're there and why they're the way they are.

So dotfiles, why do they use the home directory and not a place like /etc where the system-wide configuration resides? The reason is permissions. You see, nobody except root can actually write to /etc. So when you install a program and you want to have a configuration for it that only applies to you, the program can't write to /etc. Instead it writes to your home directory which is guaranteed to be accessible by your user and only your user (ideally and that doesn't always apply - in Debian among others you can using the default adduser stuff actually make another user that can access your home directory, do check this if you run multi-user systems anywhere). So not just .ssh/authorized_keys but also things like your .bashrc (or .zshrc if you're fancy like that) reside there. Also programs installed as your user by Python's pip are installed here, in .local/bin. Lots of things that apply to just your user reside in the home directory which coincidentally means that SSH won't be the only thing that would break either.

Long story short, the home directory is home to your personal files and to programs you installed as your user, in the form of dotfiles or even the programs themselves. But as we've established earlier, there's not really much of a reason to encrypt programs or their configuration files. So what can we do?

One of the things you could do is using another partition for your data, or even an entirely different disk altogether. Say a flash drive or something like that, which would resemble something like a D: drive on Windows. The advantage of this would be that it can be plugged out after we're done without any consequences. From the comfort of a GUI which would be unaffected by this, and credentials would be completely cleared from memory regardless of what state you put your system in afterwards. Finally the dotfiles are unaffected since that disk wasn't the home directory in the first place. It was just like any other flash drive, just encrypted. But of course if you don't even want to carry a flash drive (which is reasonable to me, I made my file server and VPN servers for pretty much that reason), nothing stops you from making it a partition on your internal storage. Regardless of which disk you encrypt, it will probably have to be a partition since file managers work better with it (read: at all). Technically you *could* encrypt a whole disk but you'd have to use the command line to unlock and mount it. The partition table is the only thing you'd gain from that which makes it totally not worth it. But it is possible.

With all of that out of the way, let's get into making one!

In order to make a LUKS-encrypted flash drive that uses btrfs internally, you can use the following commands. Btrfs has been chosen since it just works better than ext4 in the event of a power failure, and consequentially I just picked up the habit. It also supports labels which file managers can hook into when mounting it. LUKS on the other hand won't deal very well with the disk suddenly being plugged out (which makes me wonder how systemd-homed will deal with "homes on a stick" with users pulling the USB stick out without unmounting first - which is common now). Of course you can use any filesystem if it supports labels or something to make it look pretty when mounted. LUKS just sits underneath the filesystem, so it doesn't care what filesystem is used inside. Pretty cool! Not all storage solutions offer you that freedom.

For fdisk/gdisk, use these:
fdisk /dev/sdX
n
Just hit Enter from there. Fdisk (or gdisk for GPT) is really just used since parted doesn't seem to have a partition type for LUKS volumes. Parted is my partition manager of choice but my OCD took the best of me with the partition type. With a partition type "Linux" that probably didn't solve anything at all.
w

For Parted, use these (only on an empty disk!):
parted /dev/sdX
mktable gpt
mkpart primary ext4 1M 100%
quit

As far as partitioning goes, really just have backups and use your tool of choice. We just need a partition to work with, nothing else. Many ways to skin that cat and all partitioning tools would do the job.

Next up is the LUKS volume. For that, use this command.
cryptsetup luksFormat -vy /dev/sdXY
In cryptsetup you'll be asked to enter the password to encrypt your volume with. Initially it uses a password, afterwards you can add keys into LUKS too if you'd like. LUKS volumes have 10 "slots" which you can place passwords or key files in, any of which you can set to either unlock or destroy the volume if used. How exactly you want to use all this is up to you.

Open the LUKS device using this command.
cryptsetup open /dev/sdXY data
Use instead of "data" whichever name you want to give it. It'll be mounted under /dev/mapper this way.

Without a filesystem, the LUKS volume isn't very useful yet. Let's make one for it.
mkfs.btrfs /dev/mapper/data
btrfs filesystem label /dev/mapper/data data
As mentioned before, substitute "data" with the name you'd like to give your encrypted storage.

And that should be it! You can close the LUKS volume now using this command:
cryptsetup close data
and detach the USB stick. Reinsert the flash drive and you should be greeted with a screen like this.


If afterwards it mounts properly and gives you a place to store your files in, great! You're done! You've now got an encrypted storage medium to store your data in without having to buy into the idea of systemd-homed with all its complications. Congratulations!

I hope you enjoyed reading this article. It's a lot longer than my posts usually are so thanks for sticking with me. See you next time!

I took some content from this article for making mine. Do read it if any of the content in this one is confusing (and please let me know so I can improve it). Also of interest might be the FOSDEM talk from Lennart Poettering on systemd-homed which you can find here.