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

Development
,
1

Since we are going for enforce kernel module software signature verification [module signing] / disallow kernel module loading by default, should we also work towards enable Linux kernel gpg verification in grub and/or enable Secure Boot by default?

Looks doable in principle.

KVM: supports both EFI boot and Secure Boot.

On Snippet 0x0E: Booting image files and ISOs with KVM/QEMU (EFI and BIOS) - Philipp's Tech Blog see 2. Booting image files with KVM (EFI)

The Debian -- Details of package ovmf in buster ships an EFI BIOS.

sudo apt install ovmf

Other search results indicate it also supports Secure Boot.

VirtualBox: supports EFI boot (VBoxManage modifyvm "VM name" --firmware efi) but does not support Secure Boot (yet?)

Maybe we could enable Linux kernel gpg verification in grub anyhow?

Whonix Host: Would be nice if it could be booted with Secure Boot enabled. Even if security benefits are contested, this would increase compatibility/usability.

Secure Boot in Debian generally:

Secure Boot generally:

http://fit-pc.com/wiki/index.php/Linux:_Secure_Boot

Related:

Software Freedom / ethical considerations:
At least some points (I am not an expert on the subject) of which FSF are making
https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/
are very valid. Secure Boot in effect has lead to fewer people capable of running alternative operating systems such as linux distributions on the PC computer hardware which they thought they fully own as well as other hardware which as locked bootloaders which cannot be unlocked which then result in vendor lock-in with respect to the operating system. Needless to say, this is very wrong.
This development discussion however does not concern this. If Secure Boot support in Whonix gets implemented, it may improve usability (on Whonix Host) and/or security, but it does not limit what users can do with their hardware or Whonix. It will still be possible to disable Secure Boot and/or to disable Secure Boot after starting Whonix and/or to disable this in Whonix source code for custom builds.

1 Like
2

Maybe interesting for experimentation, upgrading existing VMs from grub-pc to grub-efi:

Secure Boot chain-loading bootloader (Microsoft-signed binary)

This package provides a minimalist boot loader which allows verifying signatures of other UEFI binaries against either the Secure Boot DB/DBX or against a built-in signature database. Its purpose is to allow a small, infrequently-changing binary to be signed by the UEFI CA, while allowing an OS distributor to revision their main bootloader independently of the CA.

This package contains the version of the bootloader binary signed by the Microsoft UEFI CA.

1 Like
3
1 Like
4

add EFI boot support for VM creation --vmfile --efi · Issue #134 · grml/grml-debootstrap · GitHub

I’m not objecting to adding support EFI support for VM creation, but e.g.
QEMU/KVM requires a separate efi disk (-efidisk0 ....) whereas the VMs as used in VirtualBox don’t require such an extra disk, so it’s not entirely trivial.

If anyone wants to work on this, I’d be more than happy to accept PRs, but I probably won’t have time to work on this in my spare time.

5
6
7

Turns out that sysrq does have powerful functionality that allows kernel modding which has implicaitons for secure boot, (but if only root can do it then I don’t see the point of forbidding it). As far as secure boot is concerned, I think we need to decide if the effort to make it work is worth it vs the real benefit we get. The signed shim key from MS was leaked in the past an allowed anyone to bypass their ARM non-Windows restrictions. Even if it didn’t leak, you can bet your stars that they shared it with the certain entities. So those should be able to run their code on your “secure” machine. Self signing the kernel is not even practical on an individual or UX level.

Advanced attackers don;t even have to load their extra code to attack the machine and can re-purpose code already there to carry out their instructions. This is known as data-only attacks.

https://wiki.debian.org/SecureBoot#Secure_Boot_limitations

Using SB activates “lockdown” mode in the Linux kernel. This disables various features that can be used to modify the kernel:

Lockdown mode can be disabled by pressing Alt-SysRq-x. (See “How do I use the magic SysRq key” if you have difficulty with this.) This will re-enable the above features until the next boot.

2 Likes
8

I still think secure boot would be a good idea. Secure boot would still prevent some attacks from people who don’t have the key. Many attackers probably don’t have the key so secure boot would still be an increase in security for most cases

2 Likes
9

If history is anything to go by, “secret” keys are routinely farted out in the wild making them available to everyone out there. DRM is a case in point and especially when they are used by oppressive comapnies to attack user freedom. Leaking them is a moral duty and I’d rather live in a world that is not secure but where we are free to do with our devices as we wish. Ideally users should be the ones wielding the keys but I don’t think our userbase will compile the entire boot chain and kernel en masse ,with their own signing material. I used to enforce signed modules when custom compiling grsec kernels but that ship has sailed since. The size of the UEFI software on baremetal makes the security an exercise in futility since it is a huge pile of proprietary buggy code filled with security holes. An attacker would aim higher in the chain of trust to bypass every subsequent verification step in the chian. At least in a virtual environment this would have made sense, but there are problems as I said.

With that said, there are many strong blockers to getting this to work manually let alone with scripting. more here: http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/uefi-secure-boot-support/7943/3

3 Likes
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? An overview of Secure Boot in Debian | DEBAMAX 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
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