A possible step toward integrity measurement for Fedora

The Fedora 34 release is planned for April 20 — a plan that may well come to fruition, given that the Fedora project appears to have abandoned its tradition of delayed releases. As part of that schedule, any proposals for system-wide changes were supposed to be posted by December 29. That has not stopped the arrival of a late proposal to add file signatures to Fedora's RPM packages, though. This proposal, meant to support the use of the integrity measurement architecture (IMA) in Fedora, has not been met with universal acclaim.

The purpose of IMA is to measure whether the integrity of the system is intact, where "integrity" means that the important files in the system have not been corrupted. At its core, this measurement is carried out by reading a file's contents, computing a hash, and comparing that hash to the expected value; if the values match, the file has not been altered. This measurement can be used to prevent the execution (or reading) of corrupted files; it can also be used as part of a remote attestation scheme to convince a remote party that the local system has not been subjected to unauthorized modifications.

To perform this measurement, IMA clearly must know what the expected hash for each file is; those hashes are signed with a key trusted by the kernel and stored as extended attributes. Generally, the private key used to sign these hashes is kept in some secure location, while the public key is either stored in a device like a trusted platform module (TPM) or built into the kernel binary. If all works as intended, IMA can thus be used to ensure that systems only run executables that have been blessed by some central authority, that those executables only read configuration files that have been similarly blessed, and so on. It is a mechanism for ensuring that the owner of a system keeps control of it; whether this is a good thing or not depends entirely on who the "owner" is defined to be.

The actual proposal does not go so far as to implement IMA on Fedora systems; it is limited to including signatures with every file that is shipped in Fedora packages. These signatures "will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults". Fedora users would then be able to use IMA to keep their systems from using files that have been modified since they were packaged. An actual IMA setup for Fedora can be expected to come at some future time.

Using stereotypes is always a hazardous business, but it is still probably safe to say that a typical Fedora user is uninterested in the prospect of some central authority controlling which programs may be run on their systems. That said, there may be situations where IMA could be useful. It seems that the push for these signatures is coming from the parts of the Fedora project working on initiatives like Fedora CoreOS, where much of the system is, in fact, meant to be immutable. It seems unlikely that there will be much call for IMA in, say, the desktop edition, but one never knows. It would be surprising indeed if that edition were to enable IMA by default.

In other words, Fedora users need not fear having IMA pushed on them against their will. But there are still reasons for concern about this proposal. One of those is the simple problem of bloating Fedora packages with that signature data; Panu Matilainen looked into it and found that the overhead is 1,745 bytes for each file, nearly doubling the size of smaller packages. A typical Fedora installation has many files; the extra overhead caused by the signatures adds up to a lot of extra disk space and bandwidth that may well not be useful to a large percentage of Fedora users. That has led to suggestions that perhaps the signatures should be stored in separate packages that could be installed if desired.

Florian Weimer, meanwhile, suggested that, to remain in compliance with the GPLv3 license, Fedora would have to make the signing key available on request. It's not clear that releasing that key would actually be required, though. In any case, that would be a concern for anybody distributing locked-down Fedora systems, and not the Fedora project itself. Meanwhile, as Colin Walters pointed out, any IMA implementation in Fedora would have to make it possible for users to supply their own keys.

There were also some questions about whether IMA is the best technology for this sort of assurance; a couple of participants suggested looking at fs-verity instead. It provides more efficient signature storage and verification with every read; support for fs-verity in RPM is evidently in the works. This is an option that needs to be more fully considered, given that Fedora probably needs to make a choice between IMA and fs-verity. Getting one signature into Fedora packages is a bit of a hard sell; adding a second for yet another integrity scheme would be rather harder yet.

There has been no decision made on this proposal as of this writing; that will likely have to happen at a meeting of the engineering steering committee. Given the concerns that have been raised, and the bloat concern in particular, it would not be surprising to see this idea pushed back for another release cycle. That is a lot of extra data for every Fedora user to download and store, and there is currently no established way for those users to actually benefit from it. Support for integrity measurement may eventually come to Fedora, but the feature seems less than fully baked at the moment.

Index entries for this article
Security	Distribution security
Security	Integrity

---

to post comments