(Change submitted to FESCo) |
Puiterwijk (talk | contribs) (Add RPM size numbers) |
||
| Line 45: | Line 45: | ||
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> | <!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> | ||
=== RPM Size === | |||
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system. | |||
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection). | |||
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI". | |||
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system. | |||
==== Binary RPMs on disk ==== | |||
Resigned: 462524 (452M) | |||
Resigned+IMA: 467812 (457M) | |||
This comes down to a 1.1% increase on size of the binary RPMs. | |||
==== Installed size ==== | |||
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes). | |||
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase. | |||
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system. | |||
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place. | |||
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104. | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
Revision as of 21:18, 20 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-20
- FESCo issue: #2547
- 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
RPM Size
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system. For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection). After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.
Binary RPMs on disk
Resigned: 462524 (452M)
Resigned+IMA: 467812 (457M)
This comes down to a 1.1% increase on size of the binary RPMs.
Installed size
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the /usr directory size does not change at all (both are exactly 1417064 bytes).
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase. This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.
When I install the rpm-plugin-ima, and run "dnf reinstall *", the /usr directory increases by 0.002% to 1417104.
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
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.
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. Signing can easily be disabled by updating the config file should issues arise.
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.