> From: Panu Matilainen [mailto:pmati...@redhat.com] > Sent: Tuesday, January 4, 2022 12:27 PM > 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!
Thanks Panu! I appreciate it. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora- > infrastructure _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
