On Wed, Dec 29, 2021 at 5:42 AM Roberto Sassu via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > From: Nico Kadel-Garcia [mailto:nkadel@xxxxxxxxx] > > Sent: Wednesday, December 29, 2021 10:29 AM > > [...] > > > From one of the patches: > > > > It accomplishes this task by storing reference values coming from > > software vendors and by reporting whether or not the > > digest of file content or metadata calculated by IMA (or EVM) is found > > among those values. > > > > That has no use but digital rights management. > > Hi Nico > > I give some clarifications. You've been very clear. To wit: > This applies if you want to enforce an IMA appraisal policy, > which denies access to the files if file verification fails. I That is also spelled "DRM", The idea that only code approved by a third party is permitted access to specific files violates the core principles of "free software". Putting the code in the kernel makes it more awkward for ordinary users to access the data and software on their own computers. > This will be possible because you will have the ability to load > your own GPG (or RSA) keys to the kernel to verify data source > authenticity of the digest lists. There is no need to do this in the kernel. It can happen in userland. > This applies if you want to enforce an IMA appraisal policy, > which denies access to the files if file verification fails. If you Replace the word "IMA" with DRM everywhere to understand the end goal of such features. I'm sorry if I seem a bit vehement about this. We saw this attempted with Palladium or "Trusted Computing" for boot loaders, and it wasted a lot of time for features that were defeated pretty easily in the end by virtualization. > want to enforce an IMA measurement policy instead, access > to the files will be always granted, regardless of whether > the digest lists are signed or not. IMA, in this case, will simply > record the execution of unknown files, in addition to the > digest lists you generated. > > The IMA measurement list remains in your system, unless > you decide that your system should be remotely attested > by a remote verifier. > > Roberto > > HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 > Managing Director: Li Peng, Zhong Ronghua > _______________________________________________ > 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 _______________________________________________ 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
