> Meh. I have encrypted /, /home and swap. I've disabled Secure Boot, and the TPM, and use legacy boot. I don't really trust my laptop manufacturer to get all this stuff right.

Without secureboot, how do you know your kernel hasn't been modified to log all your keystrokes (including the passphrase to your encrypted partitions)?

If someone has physical access, they can remove my keyboard and install a hardware keylogger anyway. Updating my kernel image wouldn't be very effective given that it gets updated by Arch more often than it gets booted from.

And yet, the primary use-case for file system encryption is to protect data at rest, from someone with physical access to the disk. It seems odd to draw the line at physical security so arbitrarily -- that you'd be willing to encrypt your entire root file system and then throw your hands in the air when it comes to securing a tiny boot partition.

I mainly encrypt in case of theft, /boot contains nothing valuable. / contains a lot of information about my configuration, and installed packages, as well as the key to /home

Yeah, encrypting for theft or so you have piece of mind while the machine is off but in sight is a completely valid use case.

It all depends on your threat model. In the case someone is taking the machine from me while it is off (ie: most theft or legal problems), I have a chance given FDE.

In case someone has physical access to the machine without me around, I have little to no chance, no matter what I do.

A threat model which includes an attacker having potential physical access to a machine to perform an evil maid or other blackbag cryptanalysis is a threat model which is very difficulty to accommodate, and indeed replaced boot files are just the start of your problems.

A threat model without this however, has no reason to necessitate secure boot.

As such, I see no gain in using UEFI or SecureBoot as this guide outlines. It worries me that the author didn't consider a realistic threat model when writing this guide.

This guide also suggests:

> Unless you have concerns about physical security, it is fine to write down your passphrases and keep them in a safe place away from your work desk.

So it's highly confusing what sort of threat model the author had envisioned this to be written for.

Self-Destructing Cookies is an absolute must. It's fantastic practice that makes sure that you don't have any cookies persisting longer than they should, and really reduces your footprint.

It certainly makes sense from a security standpoint, but is there any additional overhead to encrypting swap? This is the first time I've ever seen it mentioned as a security measure.

Modern systems have enough ram that swap is not much used. If it becomes necessary, the overhead of encrypting will be the least of your concerns. If your system is swapping, it's crawling anyway.

In theory anything could be in ram could also end up in swap. So yes, it is important. And yes, there is overhead, but it isn't too bad if your system isn't RAM constrained, and your CPU supports AES-NI or similar.

Ideally, you wouldn't even have a dedicated swap partition. No data is always more secure than even the most perfectly-encrypted data.

If you do have swap, though, then the encryption probably won't matter much compared to the fact that your machine is swapping in the first place.

Hibernation is a very nice feature (I use it for laptop and desktop machines) and it requires a swap partition. Also, a encrypted swap is even more important in this scenario.

In the laptop I'm typing this, swap is one of the partions over a LVM2 physical volume over LUKS.

That's why I sad "ideally" :)

You don't encrypt /usr? I really do not understand the point of encrypting a subsection of your drive.

I'm assuming he specifically mentioned encrypting /home because it's on a different partition/disk? I'm guessing /usr is on the root partition which he said he encrypts.

I guess that /usr is probably on the same partition as his root.. But depending on the distro, and how the system is managed; it may be the case that every single file in /usr comes from a package, and can be cryptographically verified using your package manager (this is certainly possible with RedHat, Debian + derivatives at least). As long as /var or wherever your package DB lives is encrypted..

>I really do not understand the point of encrypting a subsection of your drive.

To prevent people from reading sensitive data on a stolen/lost laptop.

Everything except /home is on the root filesystem. I've never seen the point in loads of mountpoints.

It's a legacy thing from running UNIX machines with small'ish hard drives. A rogue process' log file could fill the root volume and prevent logins to the system. That's why /var/log or /var was on its own mountpoint/partition. It was much more of a UNIX sysadmin thing than a LINUX sysadmin thing, as EXT2 reserved space for root to do things.

Historical reasons aside, some operating systems (like OpenBSD) are designed to be able to implement different security policies by filesystem. For example, you could mark a given filesystem as executable or non-executable, adding yet another layer of security (at least policy-wise) to a system. And really, with things like LVM and btrfs, there's little reason why this is a bad idea anymore, since expanding subvolumes/LVs is generally trivial.

You can do that in linux by bind mounting a folder to itself with the more secure options. I have a couple systems where I do this to have directories noexec, nosuid, etc. Kinda hackish but useful.

Have you never used more than one disk in a machine? Locked out of a machine because /var/log is full?

More the one disk -> LVM

And no, only /tmp has reached capacity for me when building large packages with Archs makepkg.