Changes/Signed RPM Contents

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: Peter Robinson, Patrick Uiterwijk
• Email: pbrobinson@gmail.com, puiterwijk@redhat.com

Current status

• Targeted release: Fedora Linux 37
• Last updated: 2022-04-18
• devel thread
• FESCo issue: #2779
• Tracker bug: #2076296
• Release notes tracker: #819

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.

These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.

The IMA subsystem is described on the project page.

IMA allows users to extend the trust of their system to the OS and processes. It allows the users, if they so wish, to set polices to ensure their machine and their resources are used the way they intended it to be not about restricting the use for the average Fedora user.

Like all security pieces IMA doesn't solve the whole security problem with a single option, it's not intended to, but that does not mean it doesn't provide additional value and tools for Fedora users to protect their systems. To quote a section of an LWN article:

The goals of the integrity subsystem are to detect files that have been altered, either accidentally or maliciously, by comparing a measurement of the current file contents with that of a stored "good" value; it can then enforce various file integrity policies (e.g. no access or no execution). IMA is three separate pieces: measurement, which calculates a hash of file contents; appraisal, which verifies file signatures made using the measured hashes; and audit, which records hashes and other information in the audit logs. There is also the extended verification module (EVM), which targets the measurement and protection of the file metadata, though that is not included in what she would be presenting.

It is important to note that IMA does not protect against attacks on objects in memory, it can only be used to thwart attacks that change files.

The intention here is not to ship a default policies for users but rather have sample policies that users can modify and use themselves. The Fedora IoT Edition intends to have sample policies and documentation for a number of IoT and Edge use cases.

This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them. You could for example make a policy that appraises (verifies) all files that are executed by root: appraise uid=1000 appraise_type=imasig.

Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised. This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic. We will, however, document various example policies people can adapt to their needs.

By default, the signatures will not be deployed to the file system. That will only be done once rpm-plugin-ima is installed. After that, RPM will put the signatures on the "security.ima" extended attribute on the files.

The public keys will be published on Fedora security site as well as packaged in a package (TBD) for local verification.

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 changes 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.

RPM header size bug

There was a bug in rpm from when file signatures were moved over from the header into the sigheader. Details here. This bug is fixed in Fedora and RHEL-8.

Tie-in to Secure Boot

While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot. This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.

Why in the RPM header, instead of a side-package like -debuginfo?

These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem. While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package. This would mean that the contents of an e.g. -file-signature subpackage won't be deployed to the file systems as normal files, but instead as xattrs on existing files.

That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method.

Comparison with MACs

The IMA subsystem is orthogonal to the Mandatory Access Control systems like SELinux, though it is integrated with them.

Where with SELinux you can limit who can read from or write to which file, IMA will allow you to set policies that enforce file contents to be as expected (signature validated) before they can be read/executed.

The integration is in the form that you can write a policy line that matches on certain SELinux contexts, like for example dont_appraise obj_type=var_log_t, to ensure that files of var_log_t do not need to be verified, and appraise obj_type=shell_exec_t to ensure that any shell that is executed (e.g. bash) is signed with a trusted key.

Why not ...

fsverity

As one of the fsverity maintainers has said on [1]: IMA and FS-Verity are not mutually exclusive, but at this moment IMA has a possibility to enforce a system-wide policy instead of needing the userspace binaries to check the signature status themselves.

There's currently competing proposals for upstream kernel for functionality like integration with IMA this one and this one. The proposal also requires Adding PGP support to the kernel which isn't upstream and may take some time.

The FsVerity feature also needs enhancements across Fedora including changes to Koji, additions to rpm as well as filesystems that support it. It's also got limited filesystem support, for example it's not supported on XFS which is the default on the Server Edition.

DIGLIM

The Digest Lists Integrity Module (DIGLIM) isn't actually independent of this feature, it still requires digests of the files such as the ones generated here in this proposal, it just consumes them in a different method than IMA on the end system. Rather than embedding them in xattr on the filesystem as IMA does the kernel loads them into memory.

Ultimately DIGLIM is complementary and has the ability to build on top of this functionality once this actually makes it upstream.

rpm -V

rpm -V will tell you whether a file matches the digest that's in the RPM Database, but that is useful if you think a file might have been accidentally changed. If an attacker has the opportunity to change a file on the file system, it is very likely they could also update the RPM binary (or the rpmdb) to make it not report the change.

IMA signatures will be able to identify the file to have been changed, and importantly also enable a policy which enforces the signatures, which means that if a change was made to a file that is matched by a policy, the kernel would actively refuse loading it, instead of depending on the administrator to check its validity with a known-good rpm database and binary.

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.

Having all files signed with Fedora keys would enable integration with for example Keylime, which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.

This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification. Many IoT users have expressed interest in this functionality and are already working to build on it.

IMA doesn't solve all security issues but it provides an extra useful tool to those that wish provide higher levels of security on their devices. From other proposals such as the fsverity and DIGLIM ones there is clearly a desire to be able to provide this style of extra security to Fedora users.

An advantage that this proposal has, that the others do not currently provide, is that all the functionality is in place in koji, the signing infrastructure, the various packages and kernel now and doesn't depend on out of tree patches to get into various upstream projects or work on Fedora infrastructure to be scheduled.

Scope

• Proposal owners:

The proposal owners will generate the keys in Infrastructure and get them deployed to the sign vaults, and enable the configuration options for this in robosignatory. Support for file signatures is already in the deployed versions of sigul and robosignatory.

• Other developers:

Nothing needed from other developers

• Release engineering: #10731

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 a very tiny increase in rpmdb size. 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

You can verify that a signature has been put in place by looking at the extended attribute by running: getfattr -d -m security.ima /usr/bin/bash (change /usr/bin/bash with the file to check).

The signatures can be tested “in vitro” by running evmctl ima_verify --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: None. The development work is already complete and all the infrastructure functionality is upstream.
• Contingency deadline: The signing should be turned on before a mass rebuild, and is ready to go if the change is approved.
• Blocks release? No
• Blocks product? N/A

Documentation

We intend to write documentation on how to use the IMA subsystem for docs.fedoraproject.org, but that is orthogonal to this feature itself. We expect to provide example policies users can use to base their policy on.