91–100 of 214 posts
I knew all/most of the mentioned high level details regarding SecureBoot and the TPM. However, I would have assumed that a TPM-enabled linux distro would have authenticated everything up to the FDE password prompt at a minimum as not doing so would seem to completely defy the point! Turns out this assumption is wrong.
this is a non-starter for me. the sheer number of microsoft products and programs dedicated to or endorsing a backdoor for third parties makes it untenable for any security purpose.
Earlier quoted context omitted.
do you have any more details. My first thought is "how simple" then "what am I missing"?
Have to lug a usb stick around with you and guard it 24/7 for equivalent security?
Earlier quoted context omitted.
LUKS leaves encryption metadata unencrypted. For real FDE, use "plain dm-crypt" with cryptsetup: https://security.stackexchange.com/questions/109223/what-doe... > Possible with UEFI, not BIOS/MBR. Why do you think that? I have this setup on a modern (UEFI) computer, but I use the old BIOS/MBR interface.
Huh, I thought BIOS/MBR required /boot to be on a partition at the beginning of the MBR and nowhere else, whereas UEFI allows it to be anywhere on the disk as long as its labeled with ESP. So with UEFI, you just label /boot on USB as ESP. How does it work with BIOS/MBR?
Earlier quoted context omitted.
What does a laptop with a bunch of random data on its disk and a lot of evidence of use (grime, worn keys, etc.) let you deny that the same laptop with a generic Linux boot partition followed by random data does not let you deny?
Let's put it this way: say you want to prevent somebody from getting the data on a disk. Wouldn't writing random data over the entire disk be a good idea?
No need to write anything. Better would be to use nvme tools to securely erase it ("format" is the terminology used)
On a quick skim, I could see three issues with this proposal: 1. While each home directory is individually encrypted, since /home itself is not encrypted (unlike with current uses of full disk encryption), the user login names can be found unencrypted on the disk. 2. Since each home directory is individually encrypted, backup systems like borgbackup running as root can no longer easily backup everything. 3. As far as…
And don't think of having the users do their own backups - locking users' home directories mean they won't be able to run their own cron jobs.
"The shim is signed with the aforementioned Microsoft key, that is built into all PCs/laptops." this is a non-starter for me. the sheer number of microsoft products and programs dedicated to or endorsing a backdoor for third parties makes it untenable for any security purpose.
An option that wasn't at all considered in the article is to have the initrd and (optionally) the secret key used for decrypting the disk on a separate device (or devices), for example on an 1 GB USB drive. This way the big disk can have full, real FDE (not LUKS). To an attacker not in possesion of the USB drive the big disk just looks like random data. And the USB drive can be kept on one's own person and easily des…
Poettering mentions three: The obvious 'basic' one, and two advanced scenarios focused on a thief stealing the computer and then returning it. I recall exactly one case close to the these latter two scenarios: When Mossad stole a Syrian laptop allegedly containing nuclear weapon program information and returned it[0].
However, I do not think Poettering's proposal is going to even annoy Mossad-level operations. The same people who can steal your harddrive and put it back in without notice, can for example replace your mouse with a BadUSB device and get all the info that way. Once they got hardware access, and were able to return it without the owner noticing, they have multiple ways of getting what they want. On Linux we can't be assured of controlling the hardware Apple-style.
So this is a proposal which probably doesn't stop the advanced and rare scenarios it thinks it stops. In return, we get more complexity by splitting the system into at least three components*, and going back into the partitioning mess ("You only gave 300GB to /home, in order to download the ISO you want you need to repartition the system").
IMHO, the cost-benefit ratio for splitting the system isn't good enough. We should try a simpler solution with the main purpose of stopping the basic scenario. Maybe dm-crypt everything, despite the minor speed loss? Or use fs-level authentication/encryption a-la fscrypt? Either solution still allows people who want to split the system to do so.
[0] https://www.theregister.com/2009/11/06/mossad_syria_trojan_h...
* The authenticated base system, the encrypted base system, and at least one encrypted home directory. In most system there will also be an encrypted swap partition.
"The shim is signed with the aforementioned Microsoft key, that is built into all PCs/laptops." this is a non-starter for me. the sheer number of microsoft products and programs dedicated to or endorsing a backdoor for third parties makes it untenable for any security purpose.
Strip the signature and sign with your own key? It's possible as a part of the Secure Boot model.