A possible step toward integrity measurement for Fedora [LWN.net]

A possible step toward integrity measurement for Fedora

Posted Jan 8, 2021 16:40 UTC (Fri) by calumapplepie (guest, #143655)
Parent article: A possible step toward integrity measurement for Fedora

How does this system differ from Debian's setup? I know that programs like debsums exist to verify package installations, and I believe the needed checksum files are shipped with the package.

Also, on Debian, apt-secure signs and verifies every package on installation. Does Fedora lack a similar system? Because if not, then why are the signitures for this plan problematic?

Thanks for any clarifications.

to post comments

A possible step toward integrity measurement for Fedora

Posted Jan 8, 2021 23:23 UTC (Fri) by nivedita76 (subscriber, #121790) [Link] (4 responses)

This isn't about the signatures for the RPMs themselves. It is signatures for each individual file that is part of the package. The kernel's IMA subsystem can then verify those signatures on the running system to ensure that no modified files can be accessed. This is to make sure that the files haven't been tampered with post-installation.

A possible step toward integrity measurement for Fedora

Posted Jan 8, 2021 23:31 UTC (Fri) by nivedita76 (subscriber, #121790) [Link]

Actually, it does seem similar to debsums, except that the kernel could automatically verify the hashes if configured to do so.

A possible step toward integrity measurement for Fedora

Posted Jan 9, 2021 7:49 UTC (Sat) by epa (subscriber, #39769) [Link] (2 responses)

But rpm does store hashes for the individual files which you can check with rpm -V. Since Fedora is based on rpm it would seem better to use that rather than store yet another set of checksums. (And if you do need more hashes, surely they can be computed and stored at installation time rather than bloating every package with information that is purely redundant?)

A possible step toward integrity measurement for Fedora

Posted Jan 9, 2021 8:08 UTC (Sat) by zdzichu (subscriber, #17118) [Link] (1 responses)

If you have the key used to generate the hashes on the system you want to verify (and you need to have key to generate hashes at install time), the attacker can hijack this key to generate hashes for backdoored binaries.
Attacker can also trivially replace hashes in rpmdb - it's sqlite file, after all.
And one last thing. Rpm hashes are only checked when you run rpm -V. IMA acts when file is accessed every time.

A possible step toward integrity measurement for Fedora

Posted Jan 9, 2021 14:14 UTC (Sat) by walters (subscriber, #7396) [Link]

> If you have the key used to generate the hashes on the system you want to verify (and you need to have key to generate hashes at install time), the attacker can hijack this key to generate hashes for backdoored binaries.

In the age of containerization, not every compromise is "I have full root". In the Fedora thread I gave the example of the runc vulnerability which likely also would have been blocked by an enforced fsverity/IMA type policy.

Now of course, some non-small percentage (30%) of "escalate local to root" type vulnerabilities are pure memory corruption type things in the kernel that almost nothing will stop except fixing the bug. https://en.wikipedia.org/wiki/Dirty_COW is a good example of this - SELinux, seccomp, namespaces, Secure Boot, fsverity/IMA - none of that stops a bug like Dirty Cow.

But some other percentage of vulnerabilities *would* be stopped by an IMA-type system (and the percentage of those depends on the exact enforced policy).

A good example of a class of vulnerability that IMA could block is command injection - which can still happen in fully memory safe languages like Rust for example. I think at one point e.g. bluez (bluetooth daemon) had a DBus call that let a user just run binaries because of a command injection flaw. If the IMA-type policy required only signed code to be executed, exploiting that could be a lot harder - particularly if execution of interpreters like /bin/bash is denied.

My suggestion of a local key is to clearly demonstrate that we support *user owned* keys and also "local key in kernel keyring/TPM" can generalize to a remote signing service too.

Hmm...we should really have SELinux labels on kernel keyring objects.

A possible step toward integrity measurement for Fedora

Posted Jan 8, 2021 23:27 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (6 responses)

> Also, on Debian, apt-secure signs and verifies every package on installation. Does Fedora lack a similar system? Because if not, then why are the signitures for this plan problematic?

Fedora has a similar system. However, what this article discusses is the proposal to go further than that and add file level signatures. From the proposal itself:

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

Afaik, other distributions don't do this and this proposal does not do this by default in Fedora either. Android uses fsverity which accomplishes a similar objective. It isn't problematic unless it is enforced by default and users don't have a way to opt-out and neither is the case here. The technical concerns boil down to package bloat and whether using fsverity might be a better way to accomplish the same goal.

A possible step toward integrity measurement for Fedora

Posted Jan 9, 2021 11:14 UTC (Sat) by smurf (subscriber, #17840) [Link] (5 responses)

fs-verity uses a Merkle tree to verify contents on every read.

IMA uses, AFAICT from cursory reading of the docs, a single full-file hash, plus the inode version to check whether to re-verify a file. Not so good IMHO; this seems to imply that if I can gain block-level access to a file system (this is not at all difficult if it's on a DM-managed partition) I can modify a file behind IMA's back. Ugh.

Seems to me that adding a method to sign the file's fs-verity tree might be a better option.

A possible step toward integrity measurement for Fedora

Posted Jan 9, 2021 16:05 UTC (Sat) by bluca (subscriber, #118303) [Link] (4 responses)

fsverity already supports signatures, enforced by the kernel via the .fs-verity keyring, out of the box

A possible step toward integrity measurement for Fedora

Posted Jan 9, 2021 16:16 UTC (Sat) by smurf (subscriber, #17840) [Link] (3 responses)

Ah. Thanks, I missed that. Even better.
This of course begs the question why I would want to use IMA in the first place (assuming that my file system supports fsverity).

A possible step toward integrity measurement for Fedora

Posted Jan 11, 2021 14:26 UTC (Mon) by hkario (subscriber, #94864) [Link] (1 responses)

fs-verity is a read-only file system, IMA does not require that

A possible step toward integrity measurement for Fedora

Posted Jan 11, 2021 16:29 UTC (Mon) by walters (subscriber, #7396) [Link]

No; fs-verity makes executables read-only, not a complete filesystem. You're thinking of dm-verity perhaps?

Note that with fs-verity even a "read-only" executable can be `unlink()`ed and a new one written in its place; this is why the docs https://www.kernel.org/doc/html/latest/filesystems/fsveri... talk about ensuring that the verity state of a file is validated by something (userspace, or basic support for automatic kernel verification).

A possible step toward integrity measurement for Fedora

Posted Jan 11, 2021 23:13 UTC (Mon) by ebiggers (subscriber, #130760) [Link]

fs-verity is mainly a way of hashing files, while IMA is mainly a policy for what to do with file hashes.

fs-verity does have optional support for storing signatures with files and having the kernel verify that all fs-verity files are signed by a trusted key. This is much simpler than an IMA policy but also much less flexible; e.g., userspace still needs to check which files have fs-verity enabled. It's really more a proof-of-concept, which happens to be enough for some users who don't want to use IMA.

At some point it's likely that IMA will support fs-verity hashes, so that IMA and fs-verity can be used together. They're not mutually exclusive.