Full Disk Encryption (LAPTOP users only)

[eccerr0r]

Curious of those who run Gentoo on their portable machines and how you treat your main disk - do you do full disk encrypt, either by choice or by regulations?

If you use more than one, relate to the one you use most.

Sometimes I wonder, is full disk encryption worth the overhead versus selective file encryption? FDE you pay the penalty across the whole media, where selective you only pay the price for just specific files... but now you have a target on your back ("Hey, what's this interesting encrypted file contain?")

Then if you have a machine that can do the encryption faster than a standard CPU, it won't be as much of a penalty anymore?

I've noticed that encryption is significantly more CPU intensive than parity calculation for RAID writes... much worse. Wondering if it's worth it to install FDE on my Atom 1.6GHz netbook as it's most likely to get misplaced -- alas, it is slow enough as it is, taking multiple days to emerge --update @world can only get worse with FDE.

[NeddySeagoon]

eccerr0r,

I have Gentoo on my Chromebook. I do not use full disk encryption as all the 'interesting' stuff is on my keyring.

RAID parity is 'only', lots of XOR operations. CPUs are quite good at them.
Block cyphers for any encryption are much more CPU intensive than XORs.

[pietinger]

No, I think FDE is a big nonsense, because it doesnt prevent you from offline tampering. Of course I have an encrypted home partition on my notebook if I would loose it. Here I use "fscrypt". Yes, some may say there are also user data in other directories, yes this would be true for servers, but for a simple notebook used as private desktop I have not found some user data in other dirs than in my /home.

[mike155]

Home and data partitions are encrypted on my server and on my notebook. Root and system partitions are not encrypted. I use dmcrypt.

PS: if you are considering FDE: take a look at https://xkcd.com/538/

[szatox]

No, I think FDE is a big nonsense, because it doesnt prevent you from offline tampering.

How comes? XTS mode for block chiphers was specifically designed for this very purpose, why do you claim it doesn't work?

I wonder, is full disk encryption worth the overhead versus selective file encryption?

Is the overhead of setting up selective encryption and the risk of mistakes worth saving a few CPU cycles?
I mean, unless you really NEED to leave some part unencrypted, why bother?
In my case I just left boot out, because EFI is dumb. LVM is on top of an encrypted partition. This setup is so easy to do, it would take exceptional talent to get it wrong, I don't have to think about it anymore because no data will ever be written in plaintext.
Also, I do not feel any penalty from encryption. Modern CPUs come with extensions for AES, disks are buffered in RAM, and laptops are not likely to be running IO-bound loads anyway, so whatever. It gets out of my way fast enough I don't bump into it.

[Hu]

Full disk encryption has the convenience that it is simple to reason about and simple to make secure. Every area that could be written during normal operation is covered, so there is no need to worry about some application inventing some unusual path that happens to escape encryption. For my use case, full disk encryption is about denying my data to anyone who obtains the drive, including in cases such as a warranty return of a dying drive. I don't expect it to protect against offline tampering.

[eccerr0r]

Yes. Warranty replacement and EOL parts recovery/recycling are also part of the benefits of FDE. Was thinking about trying to sell my defective disk for parts in a possible recovery situation (like using heads or pcb for possible reuse to recover data) but don't want people recovering *my* data...

Alas, I was quite disappointed by the overhead on my Celeron experiment. After cryptsetup luks was enabled, it was horrible. I may need to try on my AES enabled computers, where encryption would be a smaller portion of cpu use...

[sublogic]

/boot and the bootloader are cleartext, the rest is LVM over LUKS. Resuming from hibernation requires a passphrase. If my laptop is lost or stolen, I don't have to worry about my privacy (modulo the Android phone that spies on me 24/7).

If my laptop is recovered it's a little more complicated. Boot from rescue media, reinstall the bootloader, restore /boot from backup.
But first I should probably re-flash my BIOS. And before that maybe look for a hardware keylogger ? Hidden bluetooth ?
So s/a little// in the above.

[eccerr0r]

I should sort of clarify that FDE includes small boot partitions that unlock the majority of the disk (partition, volume, or loopfs - some regular filesystem like ext4fs is on that partition) so FDE is somewhat of a misnomer in this respect. Otherwise it's sort of impossible to boot without an external device, which anyway may or may not be what you use... Main characteristic is that it's transparent encryption.

Those with unencrypted rootfs and encrypted homefs ...that's indeed a possibility to simplify and reduce overhead, but since user files could be other places other than /home it could be tricky. Alas seems like the better plan is per-file filesystem level encryption would be better for me as I don't want to maintain a separate partition...

[Goverp]

Another vote for fscrypt; my various users' home directories get fscrypt using the user signon password, so they're secure from each other. The system directories (/usr and so forth) are unencrypted. Works for me.

I've not encrypted /root, by oversight. Should I? Probably worth it for security, but what if the system goes wrong and I need to sign in to recover? There's probably nothing there of note, but... Perhaps another poll beckons...

[eccerr0r]

I'd call things like ~root/.bash_history potentially encryption target worthy... and I have been able to login to users accounts on NFS when the NFS server croaked - so I suspect logging in as root still works if ~root is locked up and unusable -- unless something's there you need to access of course.

BTW with fscrypt, how does it deal with user cron jobs? Does it maintain keys in ram to allow this or will users need to relog on reboot to allow their cron jobs to run?

How about mail? /var/spool/mail mbox will probably still work but that should be protected too, but what about maildir?

[pa4wdh]

My laptop is a 2016 Core i5 with AES-NI and my /boot is cleartext the rest is LUKS'ed. The overhead is barely noticeable.

For those that do any kind of ecncryption: Be aware that sleep functions of laptops make it useless. The encryption keys are in memory and are either kept there or are even written to disk in case of suspend-to-disk. Both of them defeat the purpose of FDE.

[steve_v]

Portable you say? let me see, what do I got here...
Has battery, has keyboard. Does VNC, reads email, talks to old machines over serial, easy to hold in one hand. That qualifies as a "laptop", right?

Horrible Products inc.
Manufactured 2010.
1.5Ghz atom CPU.
2GB RAM.
*snap*

Yeah, totally not running full-disk encryption on that... But then who would steal it anyway?


If I want a real PC, I find a real PC.

[eccerr0r]

so it seems one needs the AES instructions for FDE to be worthwhile else overhead is too great.

Yes, I think I will have to agree that Atom portable might not be a candidate. Pretty much have the same kind of "laptop" (netbook) 1.6GHz Atom, 2GB RAM, 32GB SSD(mPCIe). It's not that the machine is valuable, it's whether the data on it is valuable, I worry about encryption keys on the disk...

[steve_v]

It's not that the machine is valuable, it's whether the data on it is valuable

None of the data I care about is stored on that machine, it's on bigger iron that's physically secure enough I'd have much bigger problems to deal with if it were stolen or misplaced.
I learned to stop worrying and love rubber-hose cryptanalysis a long time ago.

[eccerr0r]

I do have keys on the portable devices to access my home "big" devices (like ssh and vpn keys) that would not be good if they were stolen or recovered after the disk fails. These could have file-only encryption but there may or may not be some unintentionally unencrypted keys but really need to revoke those keys.

The worry is if I forget there's some other unencrypted key on the disk before loss and forget to revoke it. Even worse if for ssh keys, central revocation is something yet to be figured out, have to revoke each machine I installed the public key upon separately. At least with FDE (or with an encrypted key) I have some time to find and zap all the keys. Not all keys are encrypted so I can have my machines phone home once in a while... usually not security critical but they too need to be cleaned up.

[Goverp]

...BTW with fscrypt, how does it deal with user cron jobs? Does it maintain keys in ram to allow this or will users need to relog on reboot to allow their cron jobs to run?...

If you use the logon process to decrypt the directories (e.g. using the login password), at a first level, the user needs to be logged on for other users such as cron to read their files.

The second level is that IIUC you can set up a different means of decrypting the directories that would be tied to the cron user. Basically, the passwords you enter gives access to the fscrypt encryption key; you can also give access to that key via other passwords, such as the cron user password. What you probably shouldn't do is set up a password that's stored in the machine, of course. I did read all this stuff some time back, but haven't tried it, and forgotten the fine details.

[eccerr0r]

Yeah fscrypt seems to break some old unix traditions, hmm. would require some rework on how to set things up. I suppose it's great for systems that force you to completely logout (no cron jobs, etc.) and mail can be run on another machine that doesn't allow interactive logins...

[pjp]

"No, too much work to set up"

Mainly I don't want insufficient knowledge or experience to prevent ME from accessing the data. It is on my "someday" list.

[szatox]

BTW with fscrypt, how does it deal with user cron jobs?

Crontabs are stored under /var/spool/cron/crontabs/, so not in home. I suppose they could be excluded from encryption. It is an attack vector, though probably no worse than unencrypted root.
However, I do remember people running into troubles due to encrypted home clashing with ssh's public key authentication. Like in: you can't login via ssh because it requires access to the key stored in your encrypted home and you must provide password to decrypt your home, but ssh won't even ask for your password because it can't verify your key.
So you can't use ssh until you login locally and decrypt your home.

[pa4wdh]

I had a similar issue with my server where some parts are encrypted with LUKS.
Mounting these volumes at boot would require me to enter the passphrase at boot, which would not be a problem with a planned reboot (and me looking at the console), but for an unplanned reboot that would be problematic. In such cases i'd like the server to boot into a state where i can access it (read: at least ssh running and functioning).

The solution i have now is an extra runlevel. The "default" runlevel just boots to the bare minimum, no encryption is needed, just a few services running (syslog, ssh, network, firewall, etc).
Besides that i created a "server" runlevel which mounts the encrypted volumes and starts all the specials stuff. This means i can log in via ssh, enter the command "openrc server" and i can enter the passphrase via ssh.

Of course a server is a different from a laptop, but maybe my setup is useful to someone

[Zucca]

Doing partial disk encryption will open the possibility for an user error. However it's still popular choice it seems. And I kinda like it more since there's little sense to encrypt distfiles directory for example. Although with encryption instructions in the CPU that isn't a big deal.

One of the most critical directories to encrypt is, or course, /home, but maybe also /var/log. But encrypting /var/log might leave one guessing if something goes wrong with the decryption.

Many sides to the nth-dimensional coin.

[eccerr0r]

Technically a lot of /var also should be encrypted - log, spool, bunch of lib (my mysql databases!)... and hopefully encryption issues are logged elsewhere so they can be accessed if encryption fails. Just that /var/tmp may not be worth to encrypt!

Yeah tried to make the poll specific for machines that you do need to reboot frequently, explicitly portable/laptop where power is not guaranteed and you will be entering passwords frequently. For server use I don't know what the correct model is for the aforementioned reasons as it would be nice to be able to self-boot on power outage so FDE doesn't make sense, but it too can have disk failures and shipping off disks to places unknown is risky...

(Also shouldn't get into the paranoia of server theft here. Physical security should always be with servers, not so much with portables/laptops.)

[Hu]

One compromise approach for servers would be that the server has Full Disk Encryption for all the regular Linux data filesystems, and each drive has one unencrypted partition containing the keys for drives other than itself. Then any one drive in isolation cannot be used to recover data, but given an encrypted drive and its key-holding partner, the encrypted drive can be unlocked unattended. This guards against the warranty replacement / failed drive scenario decently well, assuming you only ever have one drive fail at a time. It provides no protection if the server is stolen in full.

[eccerr0r]

But that would be RAID level negative 1 or negative 2... one drive fails of the two, wouldn't you lose the key to the remaining drive and thus all data and can't recover any of it ? :D