initial boot medium boot options:
- chain boot hard drive (verified)
- chain boot hard drive (unverified)
- chain boot other devices? (verified/unverified)
The assumption is we boot from virtual, legacy, read-only, considered (for purposes of threat model and modelling this) secure BIOS which boots a read-only medium which contains the initial boot loader which then boots a “real” bootloader (one which actually boots a kernel).
Since the initial bootloader is considered trusted it can have the option to boot any device either verified or unverified.
The only drawback of the unverified option is usability vs security. Consider a system that was maliciously modified that would not pass verified boot anymore. Users would certainly try to boot unverified if verified boot does not work and shoot their own feet. Without unverified boot option however they could just remove the initial boot medium from VM settings and directly boot the main disk.
But it must store its files somewhere?
Protect the bootloader on the main disk for modifications: yes, that is the goal.
The BIOS is excluded in this threat model. Legacy BIOS or UEFI. Both has to be considered secure for this concept to work.
Not at all.
The initial boot disk doesn’t need to know any kernel versions. All it does is chainloading the bootloader on the main disk. The bootloader on the main disk needs to “know” kernel versions as usual (Debian auto generated grub.cfg).
Upgrades of the initial boot disk should be only required if:
- changing boot options
- changing textual description
- security upgrade of initial bootloader required [1]
Otherwise the initial bootloader wouldn’t need any upgrades ever, in theory. Even non-security upgrades could be skipped.
Probably just between major Debian upgrades sucha s buster → bullseye. I haven’t seen security upgrades for grub2 package.
That’s bad.
So either:
- ISO (virtual DVD is ready-only, right?) - and added attack surface of virtual DVD.
- or virtual harddrive but therefore breaking snapshots
Sure snapshots don’t work in a mix of read-only and read/write devices? I wouldn’t know conceptually what makes snapshots harder with read-only devices. Worth a feature request to make snapshots work with a mix of read-only and read/write devices too?
A verified boot chain that also works in persistent mode which should be as secure as Secure Boot, even better due to lack of Microsoft keys.
Looks like the initial boot disk couldn’t use shim - since that is an EFI application. But grub2 should work - if we can figure out signature verification with grub2-pc.
[1] Such as if a malicious signature of the bootloader on the main disk could be used to exploit the initial bootloader.