Producing verifiable initramfs images

Producing verifiable initramfs images

[Matthew Garrett]

I'm working on measured boot as a way to determine whether a system
has been tampered with (https://mjg59.dreamwidth.org/54203.html has an
overview of this). For this to be practical, we need to know what the
expected measurements provided by the TPM are. This is reasonably
straightforward as far as the bootloader and kernel go (we have
shipped artifacts that hash to a known value), but it's a problem for
the initramfs.

The "easiest" solution to this would be to ship an initramfs as an
artifact. This is complicated by two things:

1) Local configuration ending up in the initramfs
2) Additional files ending up in the initramfs based on system configuration

For (1), I've been playing with grub and discovered that its initramfs
code supports the following syntax:

initrd initramfs.img newc:/etc/crypttab:/boot/crypttab

which will load the initramfs, and then also read /boot/crypttab and
incorporate it into an additional CPIO archive as /etc/crypttab. The
kernel will unpack each initramfs image in turn, allowing the
/boot/crypttab file to be incorporated into the initramfs as if it had
been shipped there. This allows us to remove dynamic configuration
components from the initramfs while still allowing them to be provided
on a per-system basis. As long as the measurements verify that the
dynamic content was copied to locations that match configuration
rather than code (and, further, that said configuration doesn't alter
the behaviour of code in ways we care about for boot security), the
actual contents of the configuration files don't matter.

The second is a different problem, but still seems achievable. Each
package that potentially adds content to the initramfs could provide a
pre-build CPIO containing its code, and based on local configuration
we can ask grub to load those as well.

This would result in something that's roughly equivalent to our
current situation, but would allow us to verify that the initramfs
images containing code hadn't been tampered with. This makes it much
easier to verify that the system is in a secure state before a user
enters any credentials, avoiding attacks like
https://yassine.tioual.com/index.php/2017/04/26/backdoor-initramfs-and-make-your-rootkit-persistent/
. Users who don't need this functionality would still be able to
generate their own initramfs images as before (measured boot tracks
what was booted, but doesn't block anything from booting - if you
build your own initramfs then it'd boot fine, but give different
measurements).

A minimal proof of concept here would presumably be a patch to the
kernel package to build an initramfs binary package, and then some
additional tooling to copy appropriate config to the boot partition
and have grub pick that up. Does anybody have any strong feelings on
the topic? If not, I'll try to mock this up.

Re: Producing verifiable initramfs images

[Sam Hartman]

This is not a disagreement with anything you write.

I've noticed that there is a lot more configuration that gets encoded in
the initramfs than I thought.
The most surprising for me is that if you want to control the names of
network devices or anything else set by the .link file,
that ends up needing to go on the initramfs, because udevd will set up
network devices even if they are not needed to find the root.
Unfortunately, that means that initramfs udev configuration (including
/etc/systemd/network/*.link) tends to need to be on the initramfs.

I realize you only gave crypttab as an example, but the set of initramfs
configuration is larger than I at least expected.

--Sam

Re: Producing verifiable initramfs images

[Niels Thykier]

Matthew Garrett:
> [...]
> 
> The second is a different problem, but still seems achievable. Each
> package that potentially adds content to the initramfs could provide a
> pre-build CPIO containing its code, and based on local configuration
> we can ask grub to load those as well.
> 
> This would result in something that's roughly equivalent to our
> current situation, but would allow us to verify that the initramfs
> images containing code hadn't been tampered with. [...]
> 
> A minimal proof of concept here would presumably be a patch to the
> kernel package to build an initramfs binary package, and then some
> additional tooling to copy appropriate config to the boot partition
> and have grub pick that up. Does anybody have any strong feelings on
> the topic? If not, I'll try to mock this up.
> 

Hi Matthew,

Thanks for working on making initramfs verifiable. :)

Let me know if/when there are any changes need to dh_installinitramfs
and I will happy to review them.  At the moment, it is just an easy way
to inject "update-initramfs -u" in the relevant maintscripts if the
package has a /usr/share/initramfs-tools/hooks.

If we can solve this without using maintscripts, I would be even happier
and am ready to do my part in that if you need any help there!  I know
it is not the main goal of what you are trying to here and nor should it
be a blocker for it - this is just me hoping for the best! :)

~Niels