| 6 Oct 2024 |
 ElvishJerricco | so we might as well set up /etc | 21:05:36 |
| ElvishJerricco | like the reason systemd can boot with just /usr is because it puts all these things in their equivalent /usr locations | 21:07:26 |
| ElvishJerricco | e.g. /usr/lib/systemd/journald.conf | 21:07:41 |
| 7 Oct 2024 |
| ElvishJerricco | Huh, here's a neat trick. Useful for exactly one device, i.e. probably your root device. You can use tpm2-measure-pcr=yes in crypttab options and bind the volume to pcr 15:sha256=000...000 to get poor-man's pcrphase. You get exactly one phase :P | 03:28:52 |
|  Sam Lehman changed their profile picture. | 14:24:17 |
| ElvishJerricco | mjm: I think there's a problem with the bcachefs generator's credential based unlocking. Not that it's buggy; just that you probably have a vulnerability in your setup. I mean frankly it's probably pretty common in a lot of auto-unlock setups. | 23:13:10 |
 mjm | In reply to @elvishjerricco:matrix.org
mjm: I think there's a problem with the bcachefs generator's credential based unlocking. Not that it's buggy; just that you probably have a vulnerability in your setup. I mean frankly it's probably pretty common in a lot of auto-unlock setups. what's the vulnerability? | 23:23:16 |
| ElvishJerricco | basically, if I replace your disk with my own and trick your initrd into mounting my bcachefs, you'll mount it and boot it without error because the unlock service silently skips unencrypted file systems. Then my OS can freely use the TPM, which means it can decrypt the original disk.
The two ways to fix this are to validate the identity of the root fs before booting it somehow, or the less error-prone method IMO is just systemd-pcrphase since that just always puts the TPM in a state that won't decrypt your drive.
| 23:26:05 |
| ElvishJerricco | That's why I was looking at that "neat trick" last night. | 23:26:13 |
| ElvishJerricco | though even that's not engouh | 23:26:16 |
| ElvishJerricco | * though even that's not enough | 23:26:18 |
| ElvishJerricco | actually no that one's probably fine | 23:27:00 |
| ElvishJerricco | but pcrphase is a pain in the ass because it involves signing individual phases with a key that's unique to that phase | 23:28:43 |
| ElvishJerricco | which is why I just did the poor-man's thing | 23:28:49 |
| mjm | okay i see what you mean | 23:29:03 |
| mjm | i think the clevis set up also had that issue? | 23:30:27 |
| mjm | yeah, it also uses an exec condition in the same way | 23:31:28 |
| ElvishJerricco | mjm: The clevis setup might not have, because it probably bailed if it didn't do the decryption? | 23:31:33 |
| ElvishJerricco | oh | 23:31:33 |
| ElvishJerricco | then no | 23:31:35 |
| ElvishJerricco | heh | 23:31:36 |
| mjm | https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/filesystems/bcachefs.nix#L90 | 23:31:44 |
| ElvishJerricco | oh, right, yea, it wouldn't affect that I guess | 23:32:06 |
| ElvishJerricco | I bet it bails for LUKS or ZFS though | 23:32:14 |
| ElvishJerricco | (maybe) | 23:32:18 |
| ElvishJerricco | but yea, the 3 main options are probably: 1) Ensure the decryption goes as planned, 2) Verify the identity of the root fs, 3) Change the TPM before leaving initrd | 23:32:58 |
| ElvishJerricco | of course all three would be nice | 23:33:07 |
| ElvishJerricco | mjm: I have this for #2, but it's not for lanzaboote yet and it relies on a self-signed OS rather than any kind of machine ID. | 23:34:51 |
| ElvishJerricco | https://github.com/NixOS/nixpkgs/pull/273593 | 23:34:52 |
| mjm | the || true suggests to me that maybe this would affect zfs too? https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/filesystems/zfs.nix#L156 | 23:35:12 |
