Puiterwijk (talk | contribs) (Initial draft) |
Puiterwijk (talk | contribs) (Update with new approach) |
||
| Line 39: | Line 39: | ||
== Detailed Description == | == Detailed Description == | ||
During | During signing builds, the files in it will be signed with IMA signatures.. | ||
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and | These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults. | ||
== Feedback == | == Feedback == | ||
| Line 53: | Line 52: | ||
== Scope == | == Scope == | ||
* Proposal owners: | * Proposal owners: | ||
The proposal owners will write code to | The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults. | ||
* Other developers: | * Other developers: | ||
| Line 86: | Line 85: | ||
== Contingency Plan == | == Contingency Plan == | ||
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. If we did start signing files and something went awry, we can back out the | * Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. If we did start signing files and something went awry, we can back out the sigul configuration to sign files. | ||
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release. | If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release. | ||
Revision as of 16:42, 5 January 2021
Signed RPM Contents
Summary
We want to add signatures to individual files that are part of shipped RPMs. These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.
Owner
- Name: Patrick Uiterwijk
- Email: puiterwijk@redhat.com
- Name: Peter Robinson
- Email: pbrobinson@gmail.com
Current status
- Targeted release: Fedora 34
- Last updated: 2021-01-05
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
During signing builds, the files in it will be signed with IMA signatures.. These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.
Feedback
Benefit to Fedora
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.
Scope
- Proposal owners:
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.
- Other developers:
Nothing needed from other developers
- Release engineering:
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.
- Policies and guidelines:
No impact
- Trademark approval:
No impact
- Alignment with Objectives:
This aligns with the Internet of Things objective.
Upgrade/compatibility impact
There should be little to no impact on existing systems. If a user was already signing their own files, they will just overwrite the existing signature. If they weren’t, this adds a new extended attribute (if RPM was not asked to skip that), that is unused until they deploy an IMA policy that uses it.
How To Test
The signatures can be tested “in vitro” by running evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt.
This should result in the system reporting “<filename>: verification is OK”.
The full system could be tested by enrolling the Fedora IMA key to the kernel _ima keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).
User Experience
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.
Dependencies
No external package dependencies.
Contingency Plan
- Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. If we did start signing files and something went awry, we can back out the sigul configuration to sign files.
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.
- Contingency deadline: We could ship with this feature in an unfinished state.
- Blocks release? No
- Blocks product? N/A
Documentation
Documentation to follow.