You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
(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.The text was updated successfully, but these errors were encountered: