11–20 of 214 posts
What’s to stop this occurring to the kernel and/or boot loader? Maybe the TPM but idk
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 I could understand, this proposal does not have a mechanism to share disk space between the system and the user directories. This goes in the opposite direction of for example https://fedoraproject.org/wiki/Changes/BtrfsByDefault in Fedora 33, which allowed the whole disk to be used for files in /home, instead of always reserving IIRC 50 gigabytes exclusively for files outside /home.
I kinda think the claims about not encrypting /use are fairly dubious. What’s to stop an attacker replacing a lib with a signed+known vulnerable lib? As far as I know there’s no mechanism for revocation. What’s to stop this occurring to the kernel and/or boot loader? Maybe the TPM but idk
It should be noted that keeping it unencrypted is only for the traditional linux package manager usecase.
I have a veracrypt drive, and I regularly have to run a scan and fix on it because it's very sensitive to power cut, brutal restart, etc.
Also, it's slow. I put my firefox conf folder in it, but it slows the browser down.
Once I went full encrypted disk, but one day corruption happened, and it stopped booting. So I went back.
Only had time to skim it, but even without all the details it is an excellent overview of the state of the art regarding secure boot chain. You can learn many of the points by looking into the Android boot sequence but this is a more generic and 'everything in a single place' write-up. Especially the mechanisms behind dm-verity seem to be not widely known and - in my view- underappreciated. > *This is all so desktop/…
Are other people experiencing too many corruption problems on encrypted disks? I have a veracrypt drive, and I regularly have to run a scan and fix on it because it's very sensitive to power cut, brutal restart, etc. Also, it's slow. I put my firefox conf folder in it, but it slows the browser down. Once I went full encrypted disk, but one day corruption happened, and it stopped booting. So I went back.
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…
If you’re using LUKS-encrypted volumes for home directories nothing prevents you from enrolling an extra key file entrusted to the backup program, or to the TPM (which the backup program can be allowed to access).
Are other people experiencing too many corruption problems on encrypted disks? I have a veracrypt drive, and I regularly have to run a scan and fix on it because it's very sensitive to power cut, brutal restart, etc. Also, it's slow. I put my firefox conf folder in it, but it slows the browser down. Once I went full encrypted disk, but one day corruption happened, and it stopped booting. So I went back.
You probably have some fun disk caching turned on in the OS or your disk has a built in cache that it’s not properly flushing. I’ve seen this before with cheap SSDs.
Also, I don't have any problem with non encrypted data.
It's not as rubbish as the author wants to think. Just look at the current state of Android SafetyNet attestation - a myriad of apps refuse to run entirely (banking apps, games) or with reduced quality (Netflix) on unlocked bootloader / rooted systems. There are workarounds but these are a) a constant cat-and-mouse game and b) the only known workaround against online SafetyNet attestation (pretending that the device does not have a TrustZone element, forcing SafetyNet to Basic attestation) is bound to fail as soon as Google is reasonably certain that there is no hardware floating around that has the latest Android but no TrustZone element.
Additionally, look at what happened to Microsoft's ARM adventures. Locked down to the point of being utterly useless, on top of MS not providing a Rosetta equivalent.
The problem is that here the interests of hackers (who either want as-open-as-reasonably-possible devices or, like the author, as-secure-as-possible devices) and big corporate interests (who want to keep license holders happy like Netflix, want a way to reduce successful "my device got pwned, someone stole my money, refund me!!!" claims like banks or fight against cheaters) collide in a position that's hard to make something decent out of.