Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #66318 > unrolled thread

Producing verifiable initramfs images

Back to article view | Back to linux.debian.kernel

Contents

  Producing verifiable initramfs images Matthew Garrett <mjg59@google.com> - 2020-02-06 02:00 +0100
    Re: Producing verifiable initramfs images Sam Hartman <hartmans@debian.org> - 2020-02-06 03:40 +0100

#66318 — Producing verifiable initramfs images

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.

[toc] | [next] | [standalone]

#66320

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web