On Wed, Dec 29, 2021 at 6:39 AM Neal Gompa <ngomp...@gmail.com> wrote: > > On Wed, Dec 29, 2021 at 6:06 AM Nico Kadel-Garcia <nka...@gmail.com> wrote: > > > > 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. > > 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@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
