[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

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

Development
,
#10

Ideally:

  • For dowloaded Whonix VM images: these come with keys created by the distribution. (Useful? Necessary?) On first boot, distribution keys automatically are removed and user auto generated keys being used.
  • For Whonix VM images build from source: these come with keys created by the builder.

May not be as difficult as you think? https://debamax.com/blog/2019/04/19/an-overview-of-secure-boot-in-debian/ describes that Debian creates both, signed and unsigned packages. For example:

  • shim-unsigned
  • shim-signed

The same goes for the grub bootloader and the linux kernel.

As far as I understand:

  • Only shim is signed my Microsoft. grub and linux is signed by Debian, not Microsoft.
  • For a distribution it should be possible to sign shim (and or even grub and linux) without recompilation. Just start with the -unsigned package, then sign it, and create the -signed package for it.

Therefore removing the dependency on Microsoft keys does not necessitate require recompliation of shim, grub or linux.

While what I think may be a lot easier, I would agree that it is still a non-trivial effort to implement all of this.

That may be true however Secure Boot support for Whonix Host builds also have another goal:
Usability - ability to boot the computer without need to modify BIOS settings. Therefore worth going for even when depending shim-signed by Microsoft.

#11

Signing is something done at build time and not after the fact so I don;t think this is possible AFAIK.

For a practical compromise we can ship a custom built kernel signed with our project key that doesn’t depend on a signed bootloader. This would still provide some protection while not interfering with UX. I can look into making the virtual BIOS firmware read-only to resist malicious modification or flashing.

I want to make a clear distinction that I’m talking abut VM Whonix and not the host. I agree that for the host, the most seamless experience is to have it boot with secure boot out of the box. That is not so easy in a virtual environment though.

That won’t work in practice because every UEFI rom on baremetal out there is enrolled with MS keys. Anything else won’t work seamlessly (that’s assuming they even allow you to enroll alternative keys at all).

1 Like
#12

I guess for VMs the Secure Boot key deployment happens on the host? Can’t be done after VM import? At least on Whonix Host should be possible in theory to (re)create Secure Boot keys.

Why not use use prebuild linux-unsigned from Debian and sign it?

(Only reason against it is a custom kernel - kernel recompilation for better hardening - but that does not look too likely mid term and is offtopic here.)

That is why the title of this thread is

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

So even if we don’t figure out how to use SecureBoot and “only” figure out how to use UEFI we might be able to “enable Linux kernel gpg verification in grub”. Even without UEFI we might be able to “enable Linux kernel gpg verification in grub” - I haven’t found out if grub-pc (i.e. not grub-efi) is capable of signature verification.

Yes. Might reach same protection in VMs.

I was talking about VMs here. For VMs the only thing needed in theory:

  • use shim-unsigned package from Debian and sign it with user [or distribution key]
  • use grub-signed and linux-signed from Debian
  • configure Secure Boot of VM to use user [or distribution] key

Custom Secure Boot key seems much easier to use in VMs - at least for Whonix Host - since there we should have capability to influence which keys are used by Secure Boot and because Debian used a nice modular implementation.

However at first boot of Whonix Host, ideally shim-unsigned, grub-unsigned, and linux-unsigned would all be automated, signed with user auto generated key.

1 Like
#13

No this takes place inside the VM requiring storage of the keys in a virtual nvram.

Thanks to @madaidan’s explanation this won’t be necessary. All it takes to make the Debian signed kernel reject unexpected modules is to toggle the sysctl to enforce sig checks.

I see :slight_smile: I’ll look into the grub gpg stuff. Sounds cool.

EDIT

https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd

1 Like
#14

I see. Where’s the virtual nvram stored? A file that can be manipulated from the host?

#15

Verified VM Boot Sequence without Secure Boot

(Same security level as secure boot?)

Talking about VMs only in this post,

We could boot from a virtual, read-only (write protected) boot medium such as another virtual HDD or ISO. Such a boot medium which only contains a bootloader (shim or grub?) which only task is to verify the bootloader on the main hard drive that contains the bootloader, kernel, debian. That boot medium could be shipped on Whonix Host through a deb package.

Presuppositions:

  • the virtual BIOS cannot be flashed/compromised
  • host not compromised

boot sequence:
VM powered on -> virtual BIOS loads boot DVD ISO (or alternatively another hard drive) (contains a bootloader only) -> this initial bootloader signature is not verified but secure since boot from read-only medium -> verify bootloader on main hard drive -> bootloader of main hard drive does signature verification of kernel -> continue boot

What we need for that: grub-pc (not grub-efi) with signature verification.

By not booting from that initial boot medium (for testing or if that was broken or so), users could do regular boots without verification of the bootloader on the main drive. From the perspective of the main drive, nothing would change. Except we’d enable grub signature verification of the kernel on the main drive.

The boot medium should not load the actual kernel for simplicity of the implementation. Since it is read-only it cannot be easily updated. Kernel packages change and during kernel upgrades /boot and grub.cfg on the main disk changes. If /boot was write protected, that would fail. Therefore the initial boot medium is only a simplified alternative to EFI Secure Boot. By making the initial boot medium as simple as possible, i.e. only chainloading the next bootloader, it does not need frequent updates and does not need to be updated when kernel versions change.

If we could make grub-pc (not grub-efi) use check_signatures=enforce, then maybe we don’t need to port to EFI and/or Secure Boot soon and perhaps never?

Do you see any flaws in this concept?

1 Like
Untrusted Root - improve Security by Restricting Root
Untrusted Root - improve Security by Restricting Root
#16

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.

2 Likes
#17

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

1 Like
#18

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
#19

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
#20

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
#21

Awesome.

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
#22

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
#23

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.

#24

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?

Rationale:

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
#25

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

1 Like
#26

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
#27

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

1 Like
#28

The security of Secure Boot

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