support passing through RPM IMA signatures into ostree commit #3547
Comments
|
This code looks useful to see what we need to do on the importer side: https://github.com/fedora-iot/rpm-head-signing/blob/main/rpm_head_signing/extract_rpm_with_filesigs.py |
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Apr 15, 2022
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. Add a treefile option `ima: true` that if set, causes the final ostree commit stage to use the rpmdb to look up files, find the IMA signature in the RPM database, and then propagate that into the proper `security.ima` xattr inside the ostree commit. (The option defaults to false out of conservatism; people who want this should really be opting-in. Also the rpmdb lookups during postprocess are a speed hit) 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. Closes: coreos#3547
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Apr 16, 2022
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
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Apr 18, 2022
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
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Apr 18, 2022
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
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Apr 19, 2022
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
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
May 5, 2022
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
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
May 5, 2022
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a subset of #1883
Basically RHEL9 will ship IMA signatures, we should support passing this through into the ostree commit.
The text was updated successfully, but these errors were encountered: