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

A possible step toward integrity measurement for Fedora

Posted Jan 8, 2021 23:23 UTC (Fri) by nivedita76 (subscriber, #121790)
In reply to: A possible step toward integrity measurement for Fedora by calumapplepie
Parent article: A possible step toward integrity measurement for Fedora

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