rpm-ostree
rpm-ostree copied to clipboard
coreos
compose: support IMA/fsverity
As an additional step in boot measurement, and in order to extend the chain of measurement to the userland, it would be interesting for rpm-ostree to attach IMA digests (i.e. security.ima xattr) to committed files.
In particular, it would be nice getting to a point where we are covering the individual files in initramfs. That should in theory allow us to bridge between a measuring bootloader and the real rootfs binaries (checked out from ostree).
I am not sure if appending xattrs would break some content integrity reference with RPM pristine content, plus some RPMs may already be coming with security.ima labeled files.
In that case, it could still be worth investigating labeling files that are not coming from RPMs, e.g. content injected via treefile postprocess.
it would be interesting for rpm-ostree to attach IMA digests (i.e. security.ima xattr) to committed files.
Yes! Thanks for filing this. I would love to investigate this (part of this should be libostree work). I recently was following with great interest this thread and I want to watch the recordings when they become available.
I am not sure if appending xattrs would break some content integrity reference with RPM pristine content
Oh but we're going to intercept that anyways :wink:
plus some RPMs may already be coming with security.ima labeled files.
Not in Fedora at least. Although I think IBM (main IMA sponsor?) was working on that, you can find patches on the rpm-maint list. But it's not relevant for us because librpm isn't involved in actually writing files.
@lucab I propose we move this to a fedora-coreos-tracker issue. I think it encompasses more things; it has an impact on the administrator experience beyond just rpm-ostree.
(Also, I think we should support "sealing" after Ignition has run - in true immutable infrastructure style, /etc would be read-only after that, and we'd try to strongly enforce it or so)
@cgwalters I'm fine to also have an umbrella issue in fcos-tracker to tie all the components and parts together. But I currently don't have all the required knowledge to see the whole picture, so I didn't open that (yet).
This ticket is just to scope the initial small step of "ensure that everything has a digest in xattr", either here or in libostree.
I recently was following with great interest this thread and I want to watch the recordings when they become available.
https://www.youtube.com/watch?v=EmEymlA5Q5Q was quite interesting indeed!
I'm also investigating fs-verity, see: https://github.com/ostreedev/ostree/pull/1959 https://github.com/ostreedev/ostree/pull/2269
The reasons to go for fs-verity over IMA are:
- Files are actually read-only even to
CAP_SYS_ADMIN - Verifies file chunks rather than whole thing, meaning reduced startup latency and avoids "read amplification" for files that are only partially read
- More modern crypto
- Relatedly, I believe fs-verity better handles "offline" attacks because it validates the in-memory state
That said, as the upstream fs-verity docs note, IMA could use fs-verity as a "backend"; I think that makes the most sense. Hopefully patches happen in that direction.
The downside of fs-verity is that we will want to patch core parts of userspace (e.g. systemd) to implement things like
ExecRequireFsVerity=true
(with a well-known kernel keyring value e.g.)
However before we do anything like this I think we need to implement a basic "trusted boot" for FCOS that gets us into verified userspace so that we can have that userspace e.g. check fs-verity signatures. Most likely, I think what we should do is teach rpm-ostree how to optionally generate a combined kernel+initramfs image that is signed. See:
- https://wiki.archlinux.org/index.php/Systemd-boot#Preparing_kernels_for_.2FEFI.2FLinux
I think the systemd crew tested this in concert with sd-boot.
Definitely some useful discussion in https://lwn.net/Articles/791863/ too.
I still think it'd probably be worth adding fs-verity to xfs and enable it by default. Honestly it'd just be a tiny speed bump at best for most attackers but it'd be a useful step along the way to stronger security, and I do like the fact it actually makes files immutable beyond just the readonly bind mount.
That said...I think the only truly strong solution here is to go to a model where each node deploys a fully verified immutable filesystem tree for the OS that is signed by the end user's key. Which would be a radical change for us (both "core" CoreOS as well as e.g. OpenShift). For OpenShift we'd need to e.g. change the MCO to take the Ignition (plus kernel args) and generate a new ostree commit (or perhaps simpler to start really, use dm-verity like others are) and sign it with a key the admin provides and set everything up from Secure Boot to chain into that. This would be a nontrivial amount of work and also make things like "I want to test a kernel change on this one node" much harder (but that use case is exactly the same as an attacker wanting to persist on that node...)
Tangentially related https://puri.sm/posts/new-pureboot-feature-scanning-root-for-tampering/
Should we close this one in favour of discussions in https://github.com/ostreedev/ostree/issues/2609 and https://github.com/giuseppe/composefs ?
