| 5 Jul 2024 |
 emily | maybe it's better to revert and let encrypted swap be broken while we figure out what the proper fix is? | 11:50:59 |
| emily | (I guess this is going to require another GHSA? it's the month of security regressions…) | 11:51:25 |
| emily | not an expert in this area though so I'll defer to those who are | 11:51:32 |
 hexa | pinged elvishjerrico in #dev:nixos.org | 11:54:40 |
 raitobezarius | i'm confused by the reports | 11:57:01 |
| raitobezarius | it took me time to reload the context | 11:57:05 |
| raitobezarius | but BIOS GRUB users are protected by cryptodisk | 11:57:13 |
 Septem9er | In reply to @emilazy:matrix.org
https://github.com/NixOS/calamares-nixos-extensions/pull/25 says "#21 broke encrypted swap by mishandling the removal of crypto_keyfile.bin. This reverts the original fix. Instead, we leave BIOS the same; that was secure as it was before", I guess this was just a misunderstanding of the vuln? :/ Thanks, I didn't look at the pull request yet.
They also write:
NOTE: This is likely not a completely sufficient solution for users who choose manual partitioning. Mainly, if they create an unencrypted root partition with BIOS boot, it will still insecurely use crypto_keyfile.bin for other partitions that are encrypted.
Since they are specifically writing about unencrypted root partitions only, it seems like they thought it wouldn't be an issue for an encrypted root partiton?
Anyway, I guess this was a misunderstanding about the vulnerability. BIOS setups were definitly affected, the GHSA did specifically say it affects "non-UEFI systems".
| 11:57:52 |
| emily | In reply to @raitobezarius:matrix.org
but BIOS GRUB users are protected by cryptodisk the advisory says
Users who installed NixOS through the graphical calamares installer, with an unencrypted /boot, on either:
| 11:58:16 |
| emily | I guess the key there is "unencrypted /boot"? | 11:58:22 |
| Septem9er | In reply to @raitobezarius:matrix.org
but BIOS GRUB users are protected by cryptodisk Could you elaborate on that? | 11:58:27 |
| emily | UEFI ~always has unencrypted /boot, but on BIOS the happy path is for it to be encrypted? | 11:58:36 |
| raitobezarius | ok the key is indeed forcing to create an unencrypted /boot | 11:58:40 |
| raitobezarius | this should be an invalid configuration | 11:58:51 |
| raitobezarius | without manual partitioning, you cannot reach that state, right? | 11:59:08 |
| raitobezarius | so not sure if it's vuln or (big big) footgun | 11:59:22 |
| emily | the manual partitioning caveats are pretty scary if users have managed to independently construct an insecure configuration in the wild :( | 11:59:41 |
| raitobezarius | In reply to @septem9er:fairydust.space
Could you elaborate on that? well /boot is a cryptodisk in that situation so the keys over there are still as protected as before | 11:59:49 |
| raitobezarius | original reporter says | 12:00:27 |
| raitobezarius |
I have a similar setup with an unencrypted /boot and an encrypted /. When I start the OS it just boots all the way to user login not requiring my decryption password at any time.
| 12:00:28 |
| raitobezarius | but makes no mention of BIOs or UEFI | 12:00:37 |
| raitobezarius | * but makes no mention of BIOS or UEFI | 12:00:41 |
| Septem9er | In reply to @raitobezarius:matrix.org
well /boot is a cryptodisk in that situation so the keys over there are still as protected as before Yeah. The key is an unencryped boot partition, like it was already said. | 12:00:48 |
| raitobezarius | In reply to @septem9er:fairydust.space
Yeah. The key is an unencryped boot partition, like it was already said. yeah but let's distinguish two things | 12:01:04 |
| raitobezarius | (a) the installer creates an unencrypted /boot with an encrypted / by itself | 12:01:15 |
| raitobezarius | (b) the user forcibly creates an unencrypted /boot with an encrypted / via manual partitioning | 12:01:25 |
| raitobezarius | if we don't have (a), but we have (b) | 12:01:31 |
| raitobezarius | i'm not exactly sure we can call it a vuln, it's a footgun and we should assert not to do that or warn | 12:01:46 |
| raitobezarius | but you can do (b) all the time with any tooling | 12:01:59 |
| emily | I think it probably makes sense to err on the side of issuing an advisory if people have managed to attempt to set up an encrypted setup and been surprised to find out that it's not? | 12:02:14 |
