From: Panu Matilainen [mailto:pmatilai@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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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