Bug 869450 - autogenerate test certificates at install time instead of providing them in the RPM
autogenerate test certificates at install time instead of providing them in t...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: pesign (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-23 19:38 EDT by Mr-4
Modified: 2015-02-17 09:31 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 09:31:52 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mr-4 2012-10-23 19:38:00 EDT
Description of problem:
The whole point of using signed kernel and kernel modules is to increase security and prevent rogue code being executed as part of the boot up process. This is what signed kernel and kernel modules have to ensure as part of the new UEFI infrastructure.

With the current version of pesign a ready-made Fedora test certificate store is provided, containing Test CA and a separate public/private key pair used to sign these files. Since this is provided - by default - as part of the pesign package, anyone has access to the same key files, thus rendering the above protection completely meaningless!

What should be done, in my view, as part of the installation process, is to generate those keys at install time (in the %post section) and install these keys in the appropriate key store (by default in /etc/pki/pesign) so that each key generated as part of that installation is unique, thus enforcing the security of the kernel and its modules properly.

Version-Release number of selected component (if applicable):
0.99

How reproducible:
Always

  
Actual results:
rh-test-certs.tar.bz2 is provided containing the two keys (including the private key used for signing), thus making the protection afforded by UEFI completely useless.

Expected results:
Use certutil (enforce BuildRequires in pesign.spec) to create a new certificate store (by default in /etc/pki/pesign), generate and add a CA certificate with the appropriate  trust settings set, create a new key/certificate pair for the signing and add it to the key store - all this could be done in the %post section in pesign.spec by executing "certutil", so that the certificate/private key used for signing the kernel and its modules is unique for each machine/installation.

Additional info:
Is there really a need for separate keystore to be created/placed in /etc/pki/pesign? Could this be made optional?

The reason I ask this is because I use a different store I have with all the necessary keys and use it for various other things - like employing a usb token module to log in to my machine, or sign/encrypt software I create/use - all this by using the keys in my "general-purpose" store in /etc/pki/nssdb. 

So, if I want to use the keys I already have with pesign, what I have to do currently is to make duplicates and copy these files to /etc/pki/pesign. If I want to use my usb token (which contains my private keys, CA certificates etc) to sign my kernel and its modules with pesign, presently I can't do that.
Comment 1 Josh Boyer 2012-10-24 20:12:17 EDT
(In reply to comment #0)
> Description of problem:
> The whole point of using signed kernel and kernel modules is to increase
> security and prevent rogue code being executed as part of the boot up
> process. This is what signed kernel and kernel modules have to ensure as
> part of the new UEFI infrastructure.
> 
> With the current version of pesign a ready-made Fedora test certificate
> store is provided, containing Test CA and a separate public/private key pair
> used to sign these files. Since this is provided - by default - as part of
> the pesign package, anyone has access to the same key files, thus rendering
> the above protection completely meaningless!

Correct.  Which is why real builds in koji don't use the test certificate and instead are signed with certs provided by smartcards on special build machines.

The test certificates are provided for testing.  Not for security.
Comment 2 Mr-4 2012-10-25 09:41:16 EDT
I have highlighted, what I thought was a security risk by providing the same certificates and private keys used for signing with the srpms. 

If there is going to be a different approach when this package is going to be released "officially" then that's fair enough - I don't have a crystal ball and my name is not Mystic Meg to know what changes are planned when the package is going to be released - I have commented based on what is now at the present time, based on the rawhide release of pesign.
Comment 3 Michael Shigorin 2013-01-09 11:52:24 EST
Seems INVALID to me as one isn't likely to be going to re-enroll a regenerated key each time.  If you care for your systems you're likely to generate and use a set (or a few) of keys for local use -- and you're going to maintain local forks of the packages holding binaries to be signed, or hold these indefinitely, or invent some infrastructure for non-packaged signed binaries.

Please experiment with e.g. KVM+OVMF so that you at least clearly know what you want and what you *don't* actually want even if there's no hardware handy.

This suggestion is based on so far minor but hands-on experience. :)
Comment 4 Fedora End Of Life 2013-04-03 13:04:24 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 5 Fedora End Of Life 2015-01-09 12:26:26 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 6 Fedora End Of Life 2015-02-17 09:31:52 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.