On Tue, Dec 28, 2021 at 9:50 AM Roberto Sassu via devel <devel@lists.fedoraproject.org> wrote: > > 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) >
In general, Fedora does not include non-upstream functionality in its Linux kernel builds. This can be frustrating for development and cases where upstream requires downstream validation before upstream acceptance, but in this case, I recommend having a COPR build of the kernel with the patchset added. It also looks like there's some userspace work that needs to be done too. It'd be good to have those patches reviewed by their respective upstreams sooner rather than later. For example, I haven't seen a PR proposed to RPM for the plugin. I also agree that this feature is unlikely to affect people, as this feature will not be enabled by default. It would be extremely useful for people building Fedora-based appliances which need tamper protection for various reasons. And Fedora derivatives (like RHEL/CentOS, Amazon Linux, openEuler, etc.) can benefit from us having the functionality integrated even if we don't enable it by default. Finally, I have trouble accessing gitee.com, can you put this stuff somewhere that is more accessible (like pagure.io, gitlab.com, or github.com)? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
