User Freedom[edit]

Freedom Software can be compatible with Verified Boot. No user freedom restrictions required. While verified boot is often used to restrict user freedom, to prevent the user from modifications and installing another operating system, Verified Boot is not inherently bad. User-controlled keys are possible.

Quote ^[archive]

Nexus and Pixel lines support Verified Boot with user-controlled keys

Concepts[edit]

Verified VM Boot Sequence without Secure Boot[edit]

(Same 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 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 (such as IOS) could be shipped on Whonix ™ Host through a deb package /usr/share/verified-boot/check.iso.

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. ^[1]

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?

The disadvantage of this concept is that it is only as secure as Secure Boot. initrd could still be compromised ^[archive].

Hash Check all Files at Boot[edit]

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 ^[archive] 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.

dm-verity[edit]

Once the boot chain is verified, the kernel should verify the rest of the OS with something similar to dm-verity. Verified boot that covers only the boot chain is mostly useless but with some exceptions ^[4].

We can have 2 separate partitions for the base system and user-installed apps. Mount the base system partition as read-only and verify it with dm-verity. Mount the apps partition as /apps and chroot into it. The apps partition will not be verified.

For example:

mount /path/to/unverified_image /apps

for dir in bin sbin usr lib lib64 var etc
do
  mkdir "/apps/${dir}"
  mount -o bind "/${dir}" "/apps/${dir}"
done

mkdir /apps/{proc,sys,dev}
mount proc /apps/proc -t proc
mount sysfs /apps/sys -t sysfs
mount devtmpfs /apps/dev -t devtmpfs
mount devpts /apps/dev/pts -t devpts

apt install -o Dir=/apps $program
chroot /apps $program

mount /path/to/unverified_image /apps

for dir in bin sbin usr lib lib64 var etc
do
  mkdir "/apps/${dir}"
  mount -o bind "/${dir}" "/apps/${dir}"
done

mkdir /apps/{proc,sys,dev}
mount proc /apps/proc -t proc
mount sysfs /apps/sys -t sysfs
mount devtmpfs /apps/dev -t devtmpfs
mount devpts /apps/dev/pts -t devpts

apt install -o Dir=/apps $program
chroot /apps $program

Status[edit]

Help welcome to implement this.
https://forums.whonix.org/t/no-longer-add-virtual-dvd-drive-to-vm-by-default/9337 ^[archive] needs to be undone or considered. Could auto-add a DVD drive as long as needed.

Other Distributions implementing Verified Boot[edit]

Forum Discussion[edit]

https://forums.whonix.org/t/enable-linux-kernel-gpg-verification-in-grub-and-or-enable-secure-boot-by-default/7894 ^[archive] https://forums.whonix.org/t/fs-verity-in-linux-5-4/8911 ^[archive]

Footnotes[edit]

↑
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939188 ^[archive]
- https://savannah.gnu.org/bugs/index.php?56887 ^[archive]
↑ Quote https://www.elstel.org/debcheckroot/ ^[archive]

Usage of debsums instead of Debian-checkroot is strongly discouraged because debsums uses locally stored md5sums which can be modified by an attacker along with the files themselves. It has been meant for integrity checking not for security issues! Debsums furthermore does not provide an output as clean and neatly structured as checkroot and does not spot files additionally added to your system by someone else.
↑ https://github.com/Whonix/Whonix/blob/master/build-steps.d/2800_create-report ^[archive]
↑ For example, Whonix ™ loads apparmor-profile-everything from the initramfs which it will cover.