(Move to FeaturePageIncomplete so it does not disappear from the Features category) |
|||
| (12 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
= Package Signature Checking During Installation = | = Package Signature Checking During OS Installation = | ||
== Summary == | == Summary == | ||
One long-standing problem in Fedora is that we don't check package signatures during installation. This has been a persistent issue since the very beginning of Fedora (and even in Red Hat Linux before it.) The reason for this has always been that there's no way to form any root of trust for the signatures in the repositories, and thus no reason they wouldn't have been modified along with whatever package would need to be re-signed after tampering. | One long-standing problem in Fedora is that we don't check package signatures during initial operating system installation. This has been a persistent issue since the very beginning of Fedora (and even in Red Hat Linux before it.) The reason for this has always been that there's no way to form any root of trust for the signatures in the repositories, and thus no reason they wouldn't have been modified along with whatever package would need to be re-signed after tampering. | ||
Following the implementation of [[Features/SecureBoot]], we can extend the Secure Boot keys as a root of trust provided by the hardware against which we can verify a signature on our key files, thus guaranteeing that they're from the same source as the boot media. | Following the implementation of [[Features/SecureBoot]], we can extend the Secure Boot keys as a root of trust provided by the hardware against which we can verify a signature on our key files, thus guaranteeing that they're from the same source as the boot media. | ||
With this scheme, a repo would provide a signed file containing their signing keys, which we would verify and import on a per-repo basis. It will still be possibly to manually add repos not participating in the signature scheme, though it will require manual intervention during installation. | |||
== Owner == | == Owner == | ||
| Line 12: | Line 14: | ||
== Current status == | == Current status == | ||
* Targeted release: Fedora 19 | * Targeted release: Fedora 19 | ||
* Last updated: | * Last updated: 2013-01-02 | ||
* Percentage of completion: 5% | * Percentage of completion: 5% | ||
| Line 18: | Line 20: | ||
|- style="color: white; background-color: #3074c2; font-weight: bold" | |- style="color: white; background-color: #3074c2; font-weight: bold" | ||
|Sub-task||Percent Complete||Owner||Notes | |Sub-task||Percent Complete||Owner||Notes | ||
|- | |||
|kexec||?||vgoyal||need verification of static binaries so we can be sure peverify is real | |||
|- | |- | ||
|peverify||50||pjones||need to finish it. | |peverify||50||pjones||need to finish it. | ||
| Line 33: | Line 37: | ||
== Scope == | == Scope == | ||
See the table at | See the table at [[Features/PackageSignatureCheckingDuringOSInstall#Current_status]] | ||
== Test Plan == | == Test Plan == | ||
| Line 60: | Line 64: | ||
== Release Notes == | == Release Notes == | ||
With this release, package signatures will be checked by default during installation on compatible hardware. | |||
== Comments and Discussion == | == Comments and Discussion == | ||
Latest revision as of 09:15, 12 March 2013
Package Signature Checking During OS Installation
Summary
One long-standing problem in Fedora is that we don't check package signatures during initial operating system installation. This has been a persistent issue since the very beginning of Fedora (and even in Red Hat Linux before it.) The reason for this has always been that there's no way to form any root of trust for the signatures in the repositories, and thus no reason they wouldn't have been modified along with whatever package would need to be re-signed after tampering.
Following the implementation of Features/SecureBoot, we can extend the Secure Boot keys as a root of trust provided by the hardware against which we can verify a signature on our key files, thus guaranteeing that they're from the same source as the boot media.
With this scheme, a repo would provide a signed file containing their signing keys, which we would verify and import on a per-repo basis. It will still be possibly to manually add repos not participating in the signature scheme, though it will require manual intervention during installation.
Owner
- Name: Peter Jones
Current status
- Targeted release: Fedora 19
- Last updated: 2013-01-02
- Percentage of completion: 5%
| Sub-task | Percent Complete | Owner | Notes |
| kexec | ? | vgoyal | need verification of static binaries so we can be sure peverify is real |
| peverify | 50 | pjones | need to finish it. |
| fedora-release | 0 | pjones | 2 things here - 1) must be moved to "secure-boot" koji channel, 2) must be modified to provide a signed set of keys |
| anaconda | 0 | pjones | needs to detect that we're in a secure-boot environment and, if so, enforce signature checking on keys and packages. |
Benefit to Fedora
Allows verification of packages during installation.
Scope
See the table at Features/PackageSignatureCheckingDuringOSInstall#Current_status
Test Plan
UEFI-capable systems with Secure Boot features are available from most vendors.
The test methodology is simple - enable secure boot, create a repo with an unsigned package in it, do an install that includes that package. Installation should fail.
User Experience
Significantly similar to that of today in most cases.
Dependencies
- peverify being trusted is probably dependent on vgoyal's work for kexec+secureboot.
- "repo" in kickstart (pykickstart, anaconda) may change to specify an enforcement policy.
- There may be additional work needed to add enforcement policy on a per-repo basis to repomd.xml.
Contingency Plan
- Bump this to a later release.
Documentation
- http://www.uefi.org
- https://www.tianocore.org/
- http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256
Release Notes
With this release, package signatures will be checked by default during installation on compatible hardware.