Hi everyone thanks for the comments. I try to answer in one email. First, a clarification. Given that this feature is proposed for an open source distribution, its primary goal is to aid the users to satisfy their security needs, and let them decide how this will be done. It is not going to impose to users anything that they don't want to have. It will not be enabled by default in any case, even during an update to a newer Fedora version. It will let the users run anything they want to run. Before talking about the changes in the workload when using third-party/private repositories, it seems to me that an important requirement is to not interfere with compiled applications, or customizations made by the user. A good compromise, as I mentioned, is to not check the software executed by regular users, but only for the critical processes executed as root. The damage of executing an untrusted binary will be (likely) confined in the user environment. Reading the requirement of having third-party/private repositories (totally understandable), I realize that there must be a very clear documentation on how this case should be handled. The first point should be how to add the additional GPG keys to the kernel keyring, so that signature verification can be done. Since the RPM Fusion repository has the GPG keys (https://rpmfusion.org/keys), supporting the NVIDIA drivers or modern decoders should be possible. It could be even possible that a user installs his own GPG key (adequately protected), if he wants to sign customized software. The second point, probably more complicated, is how to identify the files that should be added to the user-generated digest list. I implemented a simple solution to this problem, a tool scans the filesystem and creates a digest list with the files that are not in the digest lists already generated (including the RPM DB). This applies for anything that is not packaged. For the rest, the kernel will be automatically synchronized every time the package manager is executed (and at boot time) and it will be transparent for the user. Just a brief note about remote attestation. I agree that we won't see soon a server we connect to with the browser proving that it is running the expected software configuration other than proving its identity. But in an enterprise network, this could be very useful. By periodically establishing a TLS connection with the nodes, you will immediately see if one node is compromised by seeing that that node is not able to respond in the handshake. I mentioned TLS because there is already a software (openssl-tpm2-engine) which takes care of the communication between openssl and the TPM. Something similar could be done for SSH. Regarding the concern that DIGLIM is not in the upstream kernel, I understand. It went through several reviews, but a decision of including it was not made. Additional reviews, in the kernel mailing list, would certainly help. Also, the comments you made will help me to make DIGLIM better, by covering more use cases. I believe that the quality of the patches is sufficiently good. I'm working on this feature for many years and a previous version of DIGLIM is already in production in our OS, openEuler. We gained a lot of experience, not only on the kernel part, but also on the complete lifecycle. While DIGLIM could be downstream for just a Fedora version, in my opinion this would help to get more feedback from the users that could speed up the decision for upstream inclusion in the kernel. If you are interested in the remote attestation part, made possible with DIGLIM, I give you few links: Linux Security Summit Europe 2019 talk: https://youtu.be/mffdQgkvDNY FutureTPM EU project final demo: https://vimeo.com/528251864/4c1d55abcd (video) https://futuretpm.eu/images/07-3-FutureTPM-Final-Review-Slides-WP6-Device-Management-Use-Case-HWDU.pdf (slides) Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua _______________________________________________ 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
