-
Notifications
You must be signed in to change notification settings - Fork 46
Description
(This issue is somewhat half baked, but there's some valid discussion to be had of composefs+IMA)
While we decided to remove composefs' builtin signature verification using the fs-verity mechanism, for systems deploying with IMA, it could make a lot of sense to use IMA to sign and verify the composefs metadata file.
I don't think initially this needs actual code changes here, it's basically documenting:
Build server
evmctl ima_sign /path/to/composefs.img
Client (e.g. in initramfs)
evmctl ima_verify /target/composefs.img
mount.composefs /target/composefs.img
This is just reusing IMA as a mechanism to sign files in a generic fashion. Verification happens in userspace.
In this scenario we aren't using fsverity on the composefs image itself...which would definitely be better. To do that though, we'd need to use IMA to sign the expected digest instead.
Now I guess things get more interesting here as one could imagine a deeper integration with IMA policies (and IMA measurement in general) a bit like what happens with devicemapper ima.
I think doing that would require driving some of the current mount.composefs
logic into the Linux kernel though. Which I guess in the end is bringing us back almost full circle in a way, except instead of using fsverity's signature support we'd be using IMA's signature support.