ddelabru left a comment (rpm-software-management/rpm#3469)
> I don't remember what exactly the signing server does (does it call rpmsign
> at some point or does it do all on its own) but clearly it gets this right,
> otherwise the normal signatures would have the same problem as well.
The signing server does handle the insertion of "traditional" signatures into
the RPM header. It can also "traditionally" sign only an extracted RPM header,
which can then be reinserted into the RPM using `rpm-head-signing`. Where the
server does **not** actually touch the header is in the case of IMA signing.
When the IMA signing feature was implemented, a decision was made to direct
users to `rpm-head-signing` to handle the operations of extracting file digests
from the RPM before IMA signing and subsequently inserting IMA signatures into
the RPM header.
I wasn't really thinking through the problem of when amongst these header
operations that region **becomes** immutable; if I understand correctly it's at
the moment that the header is signed, because anything in the region must be
part of the signed data. Part of the problem here is that I was given a
diagnostic listing of tags and region markers from an RPM header as an example
and while an "rpmdump" tool was mentioned I haven't actually found the exact
executable or command to replicate that so I can distinguish well-formed RPM
headers from malformed headers. But based on what you've said here I think I
can see an underlying problem.
It seems like the order of operations in `rpm-head-signing` is wrong for this
purpose. `rpm-head-signing` performs the insertion of a "traditionally" signed
header **and** the IMA file signatures in a single function. The implementation
of this function does the IMA signature insertion after inserting the signed
header. It sounds like this would be expected to produce a malformed header,
but then the premise of handling these operations in a single function is
already problematic because the header should not have been "traditionally"
signed until after the IMA signatures were inserted. Likewise, the header
extraction used for "traditional" signing of the header and the file digest
extraction used for IMA signing are also done in a single step; this could be
okay if users were able to subsequently insert IMA signatures into the
extracted header before signing it.
So if this is actually the nature of the problem, one solution would be to
separate these IMA signature insertion and signed header insertion operations
into different functions in `rpm-head-signing` and enable the correct workflow
(IMA signing and IMA signature insertion followed by "traditional" header
signing and signed header reinsertion), and document/communicate the problem
for users of `rpm-head-signing` and the signing server so they can adjust their
processes, preferably with a deprecation warning on the legacy functionality.
This solution could be enhanced by handling the insertion of IMA signatures
into the RPM header on the server, combined in a single request with
"traditional" signing of the header. This would enable the server to ensure the
correct order of operations (insert IMA signatures into the header, and
**then** sign the header). I think in most cases for IMA signing, we are
dealing with very large RPMs, so we will still want reinsertion of the header
into the RPM itself to happen on the client side.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3469#issuecomment-2714210467
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/3469/2714210...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
