compose: support IMA/fsverity #1883
Comments
Yes! Thanks for filing this. I would love to investigate this (part of this should be libostree work).
Oh but we're going to intercept that anyways 😉
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, |
|
@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. |
https://www.youtube.com/watch?v=EmEymlA5Q5Q |
|
See also https://github.com/keylime/keylime |
|
I'm also investigating fs-verity, see: The reasons to go for fs-verity over IMA are:
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 (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: I think the systemd crew tested this in concert with sd-boot. |
cgwalters
changed the title
|
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...) |
At the time we added fsverity code to ostree, fsverity was just a CLI tool; since then it has gained a C shared library which wraps all the signature bits and the enablement `ioctl()` conveniently. This makes it much easier for us to support signatures, so do so. Note that at this time, because ostree doesn't define a mechanism to transport fsverity signatures across repositories, this is mostly only useful for locally-generated signatures. The idea however is this is a starting point from which we can build more support, including signature transport, remote keys, etc. In order to simplify things, drop support for "opportunistic" use of fsverity. In practice we expect people using this to set it up fully, or not at all. The "read only files" aspect *is* useful, but complicated the code too much relative to its benefit. Also drop support for using fsverity for `/boot` for now; in practice most things there are read by the bootloader, which doesn't know about fsverity. Instead those should be covered by e.g. Secure Boot. This ensures that we only have one high level API `_ostree_tmpf_fsverity()` that is invoked from the core commit path. xref https://lwn.net/Articles/842002 xref ostreedev#1959 xref coreos/rpm-ostree#1883
At the time we added fsverity code to ostree, fsverity was just a CLI tool; since then it has gained a C shared library which wraps all the signature bits and the enablement `ioctl()` conveniently. This makes it much easier for us to support signatures, so do so. Note that at this time, because ostree doesn't define a mechanism to transport fsverity signatures across repositories, this is mostly only useful for locally-generated signatures. The idea however is this is a starting point from which we can build more support, including signature transport, remote keys, etc. In order to simplify things, drop support for "opportunistic" use of fsverity. In practice we expect people using this to set it up fully, or not at all. The "read only files" aspect *is* useful, but complicated the code too much relative to its benefit. Also drop support for using fsverity for `/boot` for now; in practice most things there are read by the bootloader, which doesn't know about fsverity. Instead those should be covered by e.g. Secure Boot. This ensures that we only have one high level API `_ostree_tmpf_fsverity()` that is invoked from the core commit path. xref https://lwn.net/Articles/842002 xref ostreedev#1959 xref coreos/rpm-ostree#1883
At the time we added fsverity code to ostree, fsverity was just a CLI tool; since then it has gained a C shared library which wraps all the signature bits and the enablement `ioctl()` conveniently. This makes it much easier for us to support signatures, so do so. Note that at this time, because ostree doesn't define a mechanism to transport fsverity signatures across repositories, this is mostly only useful for locally-generated signatures. The idea however is this is a starting point from which we can build more support, including signature transport, remote keys, etc. In order to simplify things, drop support for "opportunistic" use of fsverity. In practice we expect people using this to set it up fully, or not at all. The "read only files" aspect *is* useful, but complicated the code too much relative to its benefit. Also drop support for using fsverity for `/boot` for now; in practice most things there are read by the bootloader, which doesn't know about fsverity. Instead those should be covered by e.g. Secure Boot. This ensures that we only have one high level API `_ostree_tmpf_fsverity()` that is invoked from the core commit path. xref https://lwn.net/Articles/842002 xref ostreedev#1959 xref coreos/rpm-ostree#1883
At the time we added fsverity code to ostree, fsverity was just a CLI tool; since then it has gained a C shared library which wraps all the signature bits and the enablement `ioctl()` conveniently. This makes it much easier for us to support signatures, so do so. Note that at this time, because ostree doesn't define a mechanism to transport fsverity signatures across repositories, this is mostly only useful for locally-generated signatures. The idea however is this is a starting point from which we can build more support, including signature transport, remote keys, etc. In order to simplify things, drop support for "opportunistic" use of fsverity. In practice we expect people using this to set it up fully, or not at all. The "read only files" aspect *is* useful, but complicated the code too much relative to its benefit. Also drop support for using fsverity for `/boot` for now; in practice most things there are read by the bootloader, which doesn't know about fsverity. Instead those should be covered by e.g. Secure Boot. This ensures that we only have one high level API `_ostree_tmpf_fsverity()` that is invoked from the core commit path. xref https://lwn.net/Articles/842002 xref ostreedev#1959 xref coreos/rpm-ostree#1883
cgwalters
changed the title
At the time we added fsverity code to ostree, fsverity was just a CLI tool; since then it has gained a C shared library which wraps all the signature bits and the enablement `ioctl()` conveniently. This makes it much easier for us to support signatures, so do so. Note that at this time, because ostree doesn't define a mechanism to transport fsverity signatures across repositories, this is mostly only useful for locally-generated signatures. The idea however is this is a starting point from which we can build more support, including signature transport, remote keys, etc. In order to simplify things, drop support for "opportunistic" use of fsverity. In practice we expect people using this to set it up fully, or not at all. The "read only files" aspect *is* useful, but complicated the code too much relative to its benefit. Also drop support for using fsverity for `/boot` for now; in practice most things there are read by the bootloader, which doesn't know about fsverity. Instead those should be covered by e.g. Secure Boot. This ensures that we only have one high level API `_ostree_tmpf_fsverity()` that is invoked from the core commit path. xref https://lwn.net/Articles/842002 xref ostreedev#1959 xref coreos/rpm-ostree#1883
At the time we added fsverity code to ostree, fsverity was just a CLI tool; since then it has gained a C shared library which wraps all the signature bits and the enablement `ioctl()` conveniently. This makes it much easier for us to support signatures, so do so. Note that at this time, because ostree doesn't define a mechanism to transport fsverity signatures across repositories, this is mostly only useful for locally-generated signatures. The idea however is this is a starting point from which we can build more support, including signature transport, remote keys, etc. In order to simplify things, drop support for "opportunistic" use of fsverity. In practice we expect people using this to set it up fully, or not at all. The "read only files" aspect *is* useful, but complicated the code too much relative to its benefit. Also drop support for using fsverity for `/boot` for now; in practice most things there are read by the bootloader, which doesn't know about fsverity. Instead those should be covered by e.g. Secure Boot. This ensures that we only have one high level API `_ostree_tmpf_fsverity()` that is invoked from the core commit path. xref https://lwn.net/Articles/842002 xref ostreedev#1959 xref coreos/rpm-ostree#1883
|
Tangentially related https://puri.sm/posts/new-pureboot-feature-scanning-root-for-tampering/ |
|
Should we close this one in favour of discussions in ostreedev/ostree#2609 and https://github.com/giuseppe/composefs ? |
|
Yes, closing as a dup of ostreedev/ostree#2867 |
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.imaxattr) 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.imalabeled 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.
The text was updated successfully, but these errors were encountered: