On the FF extension front I'd like to add: Proxy Selector, Self-Destructing Cookies, and RefControl as recommendations.
On the FF extension front I'd like to add: Proxy Selector, Self-Destructing Cookies, and RefControl as recommendations.
Without secureboot, how do you know your kernel hasn't been modified to log all your keystrokes (including the passphrase to your encrypted partitions)?
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.
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.
In the laptop I'm typing this, swap is one of the partions over a LVM2 physical volume over LUKS.
To prevent people from reading sensitive data on a stolen/lost laptop.
And no, only /tmp has reached capacity for me when building large packages with Archs makepkg.