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

A possible step toward integrity measurement for Fedora

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

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

to post comments

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.