forked from coreos/rpm-ostree
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
build: Add support for propagating RPM IMA signatures
The alignment between ostree and IMA is actually quite good. IMA signatures are just extended attributes, and ostree has first-class native support for those. RPM represents IMA signatures in an ad-hoc way, and then a plugin pulls bits from the header and does the `lsetxattr` call. One thing that ostree is pretty good at is that one can synthesize data in memory into the final ostree commit, without actually needing it to hit the physical filesystem at build time. This is crucial for SELinux, where we want to be able to set security contexts in the resulting build without actually requiring matching SELinux policy on the *build* server. IMA has similar issues; we don't want to blindly use `rpm-plugin-ima` at *build* time. That would potentially conflict with IMA policy set up for the host system. Add a treefile option `ima: true` that if set, causes the importer to propagate the RPM IMA signatures into the proper `security.ima` extended attribute. Now, while working on this I made a fundamental realization that all along, we should have supported committing `bare-user` checkouts directly into `archive` repositories. This is how it works in coreos-assembler today. It'd make a ton of sense to add something like `ostree commit --from-bare-user` that would honor the `ostree.usermeta` xattr. (Tempting to do it by default but the compatibility hazard seems high) So for now...hack in code in our commit phase to do this. Note there was previous work here to automatically translate the `user.ima` xattr to `security.ima` (because it was apparently easier than patching rpm-ostree core?). This code kind of obsoletes that, but on the other hand one could today be writing `user.ima` attributes during a build process for things that are not from RPM, and that's kind of useful to continue to support. Though, I think we should handle that in a more principled way (that's a bigger topic). Note that Fedora and CentOS do not ship native IMA signatures by default. And in fact, there was a *huge* mess around the representation of IMA signatures in rpm - so patches to fix that landed in C9S/RHEL9 but not in at least Fedora 35 I believe. Which means: actually using this functionality for e.g. RHEL9 IMA signatures requires using rpm-ostree (and really, librpm) from a RHEL9 host system - it won't work today to "cross build" as we do with coreos-assembler. Also, testing this out with RHEL9 content I needed to do: ``` remove-from-packages: - - systemd-libs - /usr/share/licenses/systemd/LICENSE.LGPL2.1 ``` because there are two copies of that file, but they apparently have separate IMA signatures and only when IMA is enabled, ostree (correctly) reports them as conflicting. Closes: coreos#3547
- Loading branch information
Showing
8 changed files
with
128 additions
and
12 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters