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.
(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.
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.
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. :)
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
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.
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.