| 5 Jul 2024 |
 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 |
| 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 |
