On Thu, Dec 16, 2021 at 17:27:29 -0500, Ben Cotton <bcotton@xxxxxxxxxx> wrote:
https://fedoraproject.org/wiki/Changes/DIGLIM More specifically, it will make a system running Fedora attestable without the need of using dedicated remote attestation protocols. In fact, the assertion that a system is running a specific set of software will be implicitly implied by the ability of that system to correctly respond to the other peer in the TLS handshake protocol. This could be achieved with widely available software such as the Apache web server, the tpm2 openssl engine and a browser. Also [//keylime.dev/ Keylime], a Red Hat-based solution for remote attestation, could make use of the proposed scheme.
This doesn't seem very useful for the vast majority of people. The software set is going to change pretty often via updates and it will vary from user to user based on what they have installed. It might make sense in a case where you have a lot of machines you want to ensure are set up identically.
I mostly interact with my machines remotely via ssh, not tls. ssh provides a way to attest I am connecting to the expected machine already. Tampering is prevented by encrypting the disk.
It will also make Fedora able to detect tampering of its components at a more privileged level, the kernel, without the interference of user space programs. Once tampering has been detected, the actions of the altered component are prevented before that component gets the chance to perform any action. Fedora could be configured to also allow the usage of components provided by the user, if he wishes to do so (DIGLIM has a tool to build custom digest lists).
Does this work with code that is run by an interpreter? If not, it doesn't seem to make sense to not check interpreted code, while making users jump through hoops to run compiled code.
Having to sign code to run it is going to be way too much work for many Fedora users. I think doing test builds of packages would be a nightmare since the "make" (or similar system) for packages is not going to be setup to stop part way through and sign code.
As far as I can tell, the threat model this is trying to protect against is not one that I care about.
Threats that I think would find worth addressing, if it can be done practically, are evil maid attacks (both capturing the disk encryption password during boot and my password when logging in locally) and being able to easily run software that is limited to just some of my rights, instead of all of them. SELinux can help with the latter, but it isn't easy to set up custom sandboxes for software.
_______________________________________________ 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
