Re: F36 Change: DIGLIM (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 29, 2021 at 6:39 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
>
> On Wed, Dec 29, 2021 at 6:06 AM Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:
> >
> > 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.
>
> Were they really? TPM devices *are* commonly used today to support
> attestation and multi-factor encryption and authentication mechanisms.
> In many ways, the trusted computing initiative was a success. And even
> virtualization is used for implementing trusted computing in some
> platforms.
>
> With Windows 11, they're *mandatory*. Corporate policies now
> effectively *require* TPM-based mechanisms *in addition* to classical
> password or token-based multi-factor authentication.

As often occurs with DRM. it's proven burdensome and there are
numerous published workarounds, including those published by
Microsoft.

Can you point to a particular multi-factor authentication technology
that uses TPM? I'd not seen that in any server based setups, though I
could believe it exists for portable devices which support less
development. It's a problem partly because TPM puts private escrow
keys in the centralized hands, and the root keys to revoke other keys
in manufacturer's hands. The key management, and signature authority
management, is a problem. I'd be concerned at yet another attempt to
re-invent the security wheel, and secrete the wheel itself away in the
kernel without direct visibility to the user running or writing the
software.

> The difference between IMA/verity and DRM is that the former is under
> the system owner's control (in this case, *you*), and the latter is
> *not*.

Since IMA is oriented to third party vendor keys, according to its own
documentation, I don't see how this would be. It would be easier, and
more visible, for signature validation and verification to occur in
userspace. There are old tools that attempted to provide such
validation for system files, such as "chkrootkit". and for which I've
provided up-to-date bundling.

The work of signing and validating one's own data or software files is
so large, I don't see the benefit of embedding it in the kernel except
to enforce it for DRM use.

> While Palladium as a whole hasn't *yet* made it, huge chunks of it
> has. Verified and measured boot mechanisms exist in Windows and macOS,
> remote and local attestation for integrity exist for Windows, and so
> on. Some of these features exist in Linux, but not all just yet.

Nor should they, precisely for "free software" reasons. Palladium was
an attempt to provide a hardware verified, vendor signed stack from
boot to kernel to software to data files, all under the authority of
third-party generated signatures which could be revoked, at whim, by a
more root level authority, and which could be revoked or even turned
over from escrow at whim with no published procedure for when and how
such keys would be turned over. I'm concerned that these third-part
keys will suffer similar vulnerabilities.

> There is a ton of value in user-controlled versions of this
> capability. And again, none of this is on by default, it's up to *you*
> to turn it on.

Then why bother pursuing it in the kernel? Why not provide these tools
in userland, for optional activation? I hope you understand my deep
suspicion: this sounds like a replay of inefficiently and
inconsistently applied Trusted Computing features, and would seem to
provide only another hurdle.
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux