On 1/4/22 10:41, Roberto Sassu via devel wrote:
Hi everyone in the FESCo meeting yesterday, Zbigniew asked what is the relationship between this feature and https://fedoraproject.org/wiki/Changes/FsVerityRPM. I try to explain here. Both features aim at providing reference values, i.e. values of software fingerprint certified by the software vendor, in order to enforce an integrity policy. The main difference between the features is the granularity at which the vendor certifies the software fingerprints. DIGLIM adopts the current scheme of RPMs, and verifies with one signature all the files contained in the RPM. Since this data format is not suitable for use by the Linux kernel, for enforcing the integrity policy, DIGLIM extracts the digests and adds them in a hash table stored in kernel memory. Enforcement (it would be better to say security decision) is achieved by doing a lookup in the hash table. The main advantage is that DIGLIM can achieve its objective, providing reference values, without any change to existing RPMs. It could support fsverity digests, in addition to file digests, to achieve the same objective of the FsVerityRPM feature. This would require introducing a new RPM header section similar to RPMTAG_FILEDIGESTS. The FsVerityRPM feature, on the other hand, similarly to the IMA file signature approach, re-signs all (or the desired subset of) files, and adds the signatures in a dedicated section of the RPM header, with increased size overhead. The advantage of FsVerityRPM and the IMA file signatures approach is that the data format is already suitable for enforcement by fsverity and IMA.
I haven't looked at the details at all, but from a rpm POV birds-eye perspective: applauds for the approach!
Besides not bloating up RPMs with seriously expensive per-file data, this side-steps the other issues associated with both IMA and fs-verity: both require separate signing steps for the file signatures which is a non-trivial cost and complexity, and unlike those the file hashes are covered (and thus protected) by normal rpm-level signatures too.
- Panu - _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
