On Wed, Dec 29, 2021 at 5:42 AM Roberto Sassu via devel
<devel@lists.fedoraproject.org> wrote:
>
> > From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> > 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@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

Reply via email to