RE: F36 Change: DIGLIM (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Chris Murphy [mailto:lists@xxxxxxxxxxxxxxxxx]
> Sent: Thursday, January 6, 2022 9:34 PM
> Could this feature work with 3rd party kernel modules, in a UEFI
> Secure Boot (and thus kernel lockdown) context?

It could be possible to create a digest list of third-party kernel
modules. However, in the current implementation, DIGLIM
is not used as an alternative for kernel module verification.
Theoretically it is possible, you could extract the digests of
kernel modules from the signed RPM header and use those
digests for verification.

However, the trust problem remains. If your kernel does not
trust the PGP key of the repository providing third-party
modules, the kernel would refuse to access the RPM header.
The user has to trust the additional key.

Whether it is better to trust an external repository to
adequately protect the private key used for signing, or to
keep the private key in the system that would load the
third-party kernel modules is a difficult decision, and probably
each user would like to make that decision.

Personally, I would find something like this acceptable.
Currently, Fedora vouches for the source code of the packages
that it provides, for building the source code correctly, and
for adequately protecting the private key used to sign the
packages.

Fedora could provide an additional repository for which
it does not vouch for what the software does on the system,
but only that the source is reliable (e.g. the software is made
by NVIDIA) and that the software is coming from that source.

The key used to sign those packages could be embedded in
the kernel (so that there are no problems verifying it from
the boot loaded), but disabled by default. That key can be
loaded upon user request (e.g. through an option in the kernel
command line).

In my opinion, the guarantees provided by such solution are
much higher than using external repositories or having the
private key in the same system that is going to use the
third-party kernel modules.

> Workstation working group is tracking this problem as
> https://pagure.io/fedora-workstation/issue/155
> 
> If DIGLIM could be used for this use case, I further wonder whether
> it's possible to have multiple signatures for different portions of a
> kernel module? The purpose, is so NVIDIA can sign their proprietary
> binary blob (because it's theirs, no one else's, and therefore they
> should sign it). Next,either (a) Fedora (b) RPM Fusion (c) the user,
> can sign the remainder of the kernel module (the parts that are open
> source anyway). It's an open question who could or should sign
> NVIDIA's key, to narrowly indicate trust. And also a mechanism for
> revoking that trust without breaking everything else.

The DIGLIM approach would be to have an additional user
space parser that takes the NVIDIA blob as an input (it must be
signed with a key that the kernel trusts) and that does some
calculations to determine what the digest of the built kernel
module will be. The additional parser will then upload the
digest to the kernel. The real process of building the kernel
module can be done in an untrusted way in user space.

I don't see it too much viable. The complexity of the parser
doing the calculations will be very high (maybe it needs to
have logic from gcc).

The main point is how to guarantee that the transformation
from the NVIDIA blob to the kernel module is done right.
To guarantee that for the local system, it would be necessary
to enforce a heavy integrity policy (not only on the executables,
but also on all the inputs used for the transformation). It is
much easier if users trust a building infrastructure to do that.

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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux