enable Linux kernel gpg verification in grub and/or enable Secure Boot by default

That sysctl wasn’t to enforce sig checks. It prevents all module loading/unloading after it’s set. To enforce sig checks, we need to use module.sig_enforce=1 as a boot parameter which security-misc already sets.


No it is an emulated device not merely some file we can manipulate.

1 Like

Exactly so.

So the point of this implementaiton is to protect the bootloader from modification vs just the BIOS if I understand correctly? Then that’s a good way to do it. Le’s stick with a second virual HDD since adding a virtual cd drive device can increase attack surface.

No, but I assume this will need timely updates to keep up with kernel updates? Will this be required every point release or just major ones when stable next rolls around? One won’t be able to take snapshots with any read-only devices attached.

What adavantage does this entire implementation have over booting Whonix live though where we can be sure the kernel can’t be modified?

1 Like

Tried setting reaonly for the bios loader tag, Result: libvirt complains that Apparmor conflicts and VM does not start, I tried looking for a matching bios firware file under /usr/share/qemu without success.

1 Like

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.

1 Like


I mean that’s kind of the point of read-only, the state cannot be saved. It could be a conscious design decision. I think this is very good in case someone is using Live Whonix they can’t save the state and defeat the amnesic protection.

That’s the way to go given the limitations IMO.

Yes they are stored on disk in a binary format though. Only one qemu can understand.

How could we prevent this? Is there some way the bootloader on the main drive can detect it was booted without the protected one and flash a big neon warning on the splash screen?

1 Like

I think from perspective of a virtualizer snapshot of read-only mode makes sense. The point of read-only mode isn’t necessarily amnesia. One might experiment with an ISO for debugging purposes and wishing to revert to previous states to experiment from one thing to the next one over and over.

No realistic ones. A custom VM GUI. A fork of virt-manager or rewrite. Unrealistic. Users who wish to debug or customize without keeping security in mind are more likely to shoot their own feet.

That warning would only be useful for educational purposes. In case of a unverified boot of a maliciously altered kernel, malware could just disable that warning.

For education purposes, a systemd unit could check at somewhat early/middle boot if the initial boot medium is attached. And if not, create a state file. Once the GUI (X) is started, a warning popup could be shown. Or all of it could be implemented even in whonixcheck. There’s no need to do this at the bootloader stage since by the time it’s not security relevant anymore anyhow.

1 Like

Maybe nice helper tools. Dunno if still required nowadays.

But first grub2 check_signatures=enforce needs to be figured out which I failed so far with grub-pc.

grub2 feature request - DRAFT

To be posted against grub2 upstream as well as against Debian.

Please comment on / rewrite / improve this draft.

grub-pc check_signatures=enforce support (BIOS) (non-EFI)

Could you please make it possible to do signature verification with grub-pc too?


We, the maintainers of Linux distributions that primarily run inside VMs (Whonix; Kicksecure) would like to implement verified boot. Not necessarily Secure Boot.

At the moment, there are no tools that can create VM images (with Debian Linux) which support EFI booting. Also, support by virtualizers such as KVM, Xen, VirtualBox for Secure Boot is either non-existing or undocumented.

Another reason is, that inside VMs we don’t necessarily need the complexity of EFI.

Instead we could boot unverified (usual virtual BIOS legacy boot) from a virtual, read-only (write protected) boot medium (such as ISO). That boot loader on the initial boot disk (grub2) could then verify and chainload the boot loader (grub2) on the main disk. In result, we would have a verified boot sequence.

1 Like

Debian feature request: grub-PC check_signatures=enforce support (non-EFI)

1 Like

debian-kernel mailing list: Guaranteeing initramfs integrity during Secure Boot

[1] Note that this doesn’t do much against an adversary with a kernel 0day.
It’s not meant to.

This should be effective against an adversary that gains physical access to a
device, yet cannot tamper with the live system (by plugging in a device that
exploits a buggy driver, by messing with the memory bus or a DMA-capable
interface, …) and cannot replace the firmware.

As you can see, this does not outright prevent evil-maid style attacks:
the goal here is to make such attacks harder/less practical.

1 Like

Not much Ubuntu specificity and general principles might be learned from this software:

1 Like

The security of Secure Boot


An interesting comment which I don’t agree fully with but it raises and interesting point about initrd making this a kinda pointless exercise:

Lets say it would help to secure a system with enabled encryption. This might help when there is no way to get a custom signed binary. Then maybe bitkeeper would be a tiny bit more secure. I doubt that for Linux solutions as the logic is in the initrd. You could still modify that even if you could not load a modified kernel module (i still want to see that working). It is very unlikely that you can sign your initrd or you have to store the public key for that unencrypted somewhere. So what did you gain this time? Maybe a tiny bit in the case that you could not sign your own binaries. If you can do and use an initrd, that will be the weak point (and it was the weak point before as well).

So what can you do? Rely on hardware encryption if you need full security. Forget secure boot, it will not be more secure. All you can use it for is that you can not boot other systems that easyly (just like on the arm plattform).

Date: 2012-07-25 02:50 pm (UTC) From: [personal profile] mjg59

You’re completely right, secure boot does not prevent attacks that it is not intended to prevent.

grub bug #56887 grub-PC check_signatures=enforce support (non-EFI).

Hash Check all Files at Boot

Higher security level as Secure Boot.

Talking about VMs only in this concept.

We could boot from a virtual, read-only (write protected) boot medium such as another virtual HDD or ISO. Such a boot medium which runs a minimal linux distribution which then compares against checksums from Debian repository on the main boot drive:

  • The MBR (master boot record)
  • The VBR (volume boot record)
  • [A] the booloader
  • [B] the partition table
  • [C] the kernel
  • [D] the initrd
  • [E] all files shipped by all packages

There are tools that can help with checking all files on the hard drive such as debsums . However, while debsums is more popular, it is unsuitable. [2]

A tool such as debcheckroot might be more suitable for this task.

During development of Verifiable Builds experiences were made with verification of MBR, VBR, bootloader, partition table, kernel and initrd. Source code was created to analyze such files. [3]

Extraneous files would be reported, with option to delete them, to move them to quarantaine and/or to view them.

Initrd is by Debian default, auto generated on the local system. Hence, there is nothing to compare with from Debian repository. However, after verification of everything (all files from all packages) it would be secure to chroot into the verified system and to re-generate the initrd. Then to compare both versions. This might not be required if initrd can be extracted and compared against files on the root disk.

That boot medium (such as IOS) could be shipped on Whonix Host through a deb package /usr/share/verified-boot/check.iso .

Disadvantage of this concept might be that it might be slower than dm-verity. On the other hand the advantage of this concept is that this does not require a OEM image. Also it might be more secure since it does not verify against an OEM image but would verify the individual files. Another advantage is that users are free to install any package and not limited by a readonly root image. Users do not have to wait for the vendor to update the OEM image.

1 Like

Absolutely brilliant. I dont think we should judge performace just yet without having tried it.

How about splitting the process so that the most lowlevel essiential components are checked before boot and the rest can be done later after the important components are given the green light - during system run?

1 Like

It’s not entirely based on theory.

Using debsums (which that actual implementation should not use as explained in the concept) (also since it uses md5sums) - which is good enough for a quick performance test…

time sudo debsums -s

real 1m37.632s
user 0m27.825s
sys 0m11.242s

To add to that time:

  • time to boot into the verification system
  • some other stuff (initrd, bootloader, …) but maybe these are negligible
  • time to boot into the actual system

Any code executed could fake the results of verification. Seems hard to make the boot only really execute any files which are already verified. A lot more complex.

1 Like

Some interesting projects that may help:

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]