On Thu, Dec 16, 2021 at 17:27:29 -0500,
Ben Cotton <bcot...@redhat.com> 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@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
