[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Verified Boot, Secure Boot, dm-verity, debcheckroot

I am very interested in Verified Boot. Was wondering how it could be
implemented on a Linux desktop distribution such as Debian. I would like
to implement in Debian derivatives, that I maintain (Whonix, Kicksecure).

Came up with some ideas which I will share here.


= User Freedom =

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.


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

= Concepts =
== Verified VM Boot Sequence without Secure Boot ==

(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`.


* 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

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939188
* https://savannah.gnu.org/bugs/index.php?56887

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

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

initrd could still be compromised:

== 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

Quote https://www.elstel.org/debcheckroot/

> 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.

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.



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.

= Status =
Help welcome to implement this.

= Other Distributions implementing Verified Boot =
* https://docs.clip-os.org/clipos/boot_integrity.html
* https://source.android.com/security/verifiedboot/
* https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot

= Forum Discussion =


Elmar Stellnberger:

> Dear readers of debian-security
>   I have just released debcheckroot-v2.0:
> https://www.elstel.org/debcheckroot/
> The new tool can be used to check a Debian installation also against
> previously unknown rootkits. It has many improvements towards
> debcheckroot-v1.0:
> # usage of direct comparison or creation and usage of sha-256 lists
> instead of the unsafe md5sums provided in the package header
> # allow usage of multiple changeable media: i.e. DVD & BD-SL
> verification rather than just BD-DL verification
> # testing of symbolic links, of user, group and file-mode
> # scanning the home directory for odd filenames that contain control
> characters, on request: listing all hidden binary files in the home
> directory
> # download only mode + shuffling of download order for package download
> via Tails/Tor and subsequent offline verification
> # use of Python3 instead of Perl with built in support for tar, xzip,
> gzip and bzip2; no more external helper programs required, works from
> any live cd!
> Finally debcheckroot-v1.0 did no more work with current versions of
> Debian as Debian now uses xzip instead of gzip. The new program supports
> any of xzip, gzip and bz2 for compression of the data.tar.xz and the
> controls .tar.xz inside the .deb ar-archive. Files are merely unpacked
> in memory so debcheckroot keeps being quite efficient.
> I would be happy to discuss the new release here or to assist anyone who
> wants to test the new tool!
> Regards,
> Elmar

Reply to: