| 5 Jul 2024 |
 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 |
| raitobezarius | what i understand Septem9er, is that, you proved (b) | 12:02:19 |
| raitobezarius | i think it's premature to think of filing an advisory without proving (a) at least once | 12:02:47 |
| raitobezarius | via static analysis or some recipe to reproduce | 12:02:53 |
| raitobezarius | as soon as (a) is proved, yes, an advisory must be filled | 12:03:04 |
 Septem9er | In reply to @raitobezarius:matrix.org
(b) the user forcibly creates an unencrypted /boot with an encrypted / via manual partitioning Yeah sure, it's less of an issue if it only applies to manual partitioning. However, the installer should not place secrets in the boot partition in this case. That is an issue. | 12:03:23 |
| raitobezarius | that's inherent to how this graphical installer works | 12:03:46 |
| raitobezarius | what is missing is an warning or an assertion | 12:04:17 |
| raitobezarius | but given the current state of maintenance of things, this installer should honestly just retired | 12:04:40 |
| raitobezarius | * but given the current state of maintenance of things, this installer should honestly be just retired | 12:04:53 |
| Septem9er | In reply to @raitobezarius:matrix.org
that's inherent to how this graphical installer works This definitly is not the case with calamares on other OSes. You should be allowed to have an unencryped boot with an encrypted root without the installer putting your secrets into the unencryped boot partition. | 12:05:10 |
| raitobezarius | it's given a false sense of support to many folks and if people who are installing Heads are using it, it creates sad incidents like those | 12:05:17 |
| raitobezarius | In reply to @septem9er:fairydust.space
This definitly is not the case with calamares on other OSes. You should be allowed to have an unencryped boot with an encrypted root without the installer putting your secrets into the unencryped boot partition. that's not what i'm saying | 12:05:28 |
| raitobezarius | * it has given a false sense of support to many folks and if people who are installing Heads are using it, it creates sad incidents like those | 12:06:25 |
| Septem9er | In reply to @raitobezarius:matrix.org
what is missing is an warning or an assertion There is a warning, see this screenshot.
But it sound more like the general "unencryped boot partitons can be unsecure" than an "we will place your FDE secrets there".
| 12:06:53 |
 syd installs gentoo (they/them) | Please move to #security-discuss:nixos.org | 12:07:07 |
| raitobezarius | sorry, right | 12:07:22 |
|  ElvishJerricco joined the room. | 12:42:26 |
| ElvishJerricco | In reply to @septem9er:fairydust.space
Hey,
it seems like there is an regression of CVE-2023-36476 in the Nixos-calamares-extension, aka. the graphical NixOS-Installer.
The commit fixing this was reverted for some reason. It seems like they wanted to fix it another way in this commit. I haven't really looked into what they try to do in this commit, however the commit message was the following:
Do not use crypto_keyfile.bin in UEFI, but leave BIOS the same.
Which doesn't really make sense to me, because the original CVE applied to BIOS systems mostly. So leaving BIOS systems the same wouldn't fix the issue.
Someone reported this here, I could reproduce this with the latest Nixos-GNOME ISO, with the following steps:
- Start the ISO on a BIOS (legacy) system / in BIOS mode
- Select manual partitioning in the installer
- Create an unencrypted legacy-boot partition with mountpoint /boot
- Create an encrypted root partition with mountpoint /
After the installation is done, there is an luks-keyfile in an zstd/cpio archive in /boot/kernels/***-secrets, which does open the root partition.
yea, the reason for that revert commit was that the original fix was wrong, so I just reverted and re-did it | 12:45:20 |
| raitobezarius | discussions in #security-discuss:nixos.org ElvishJerricco | 12:45:52 |
|  terru joined the room. | 13:41:22 |
|  @manuelbaerenz:matrix.org left the room. | 16:10:18 |
|  nope (backup) joined the room. | 16:40:16 |
|  aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) changed their display name from aleksana to aleksana (force me to bed after 18:00 UTC). | 18:59:08 |
| 7 Jul 2024 |
|  @1h0:matrix.org left the room. | 08:53:49 |
 hexa | https://securitylab.github.com/advisories/GHSL-2024-089_youtube-dl/ | 18:51:25 |
