Arnt Gulbrandsen <a...@gulbrandsen.priv.no> wrote: > Simon Hobson writes: >> Isn't it the bootloader that UEFI loads and runs, and as long as the >> bootloader (Grub) is signed, then UEFI should boot it and grub can boot >> anything you want. Kind of blasts the argument that secure boot is either >> essential or secure out of the water when you can sign one bit of >> "insecure"* code and have it load anything. > > I wonder if you misunderstand, perhaps...
Evidently ... > I have a linux laptop with data you shouldn't access. You may assume it's > sensibly configured (secure boot, luks, etc, but standard hardware, no > epoxy). Can you explain to me how you would evade its security? Not really, but I don't see any sign of that as a question in the post I was replying to ! But just thinking off the top of my head ... The bootloader can't be on an encrypted partition, unless the EFI supports that. So you have part of the boot process which isn't secured. Therefore anyone with access to the hardware can interfere with the bootloader and in theory, that could include booting the kernel in some non-standard way. It's not beyond the bounds of possibility to sniff the password* for unlocking your encrypted volume and storing that for later retrieval before booting your chosen setup without further modification. * I'mm assuming that to access the encrypted volumes, either the key must be accessible to the bootloader (and hence to any other signed bootloader someone might install), or there is a password needed to unlock it (in which case there's scope for sniffing the keystrokes). The way round this is a completely secure boot process - where the bootloader needs to be signed, and will only load signed configs, and will only run signed binaries, and so on. This is much as certain organisations have been trying to push for a while - against a "certain amount of pushback" from those of us who want to be able to run what we want on our own hardware. The fact that we have a "signed" bootloader that will load unsigned configs and binaries (ie our choice of kernel) makes a hole in the system. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
