Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

integration with IPE tracker #360

Open
cgwalters opened this issue Sep 25, 2024 · 3 comments
Open

integration with IPE tracker #360

cgwalters opened this issue Sep 25, 2024 · 3 comments

Comments

@cgwalters
Copy link
Contributor

As of the current Linux kernel merge window, the IPE LSM was merged. Per the docs an example policy is e.g.

op=EXECUTE dmverity_signature=TRUE action=ALLOW

This relies on the idea that the dm-verity signature was verified in-kernel I believe. In contrast, the fsverity bits in IPE match by digest (annoying at scale) or rely on the in-kernel fsverity signatures which the fsverity maintainer doesn't like.

As folks here know with composefs we can combine the advantages of these. I think there is a bit of plumbing work that needs to be done, Eric Biggers (fsverity maintainer) noted this at one point.

I think in the end state what we want is something like:

op=EXECUTE composefs_signature=TRUE action=ALLOW

Now, this gets into a messy topic of whether signatures are verified in kernel or in user space, and if in user space how we set a property that then later is trusted by the kernel.

And since composefs doesn't exist at the kernel level maybe this would need to be e.g. op=EXECUTE overlayfs_fsverity_signature=TRUE action=ALLOW or so (and covering both the loopback-erofs fsverity vs backing file fsverity.

And in general I think we need propagate metadata across our chain of 3 components (overlays, erofs, and the backing filesystem) so the higher level overlayfs inode that the LSM sees can reliably see that e.g. fsverity was required and enabled on the backing file, etc.

@jluebbe
Copy link
Collaborator

jluebbe commented Sep 25, 2024

File-backed mount support for EROFS has been merged for Linux v6.12. As that avoids the loopback device, it should make it easier to associate the fsverity signature to the erofs mount.

@hsiangkao
Copy link
Contributor

hsiangkao commented Sep 25, 2024

File-backed mount support for EROFS has been merged for Linux v6.12. As that avoids the loopback device, it should make it easier to associate the fsverity signature to the erofs mount.

Geert has requested for marking it as default n https://lore.kernel.org/r/CAMuHMdVqa2Mjqtqv0q=uuhBY1EfTaa+X6WkG7E2tEnKXJbTkNg@mail.gmail.com
That was why I tended to avoid this stuff in the beginning not because it cannot (just because the kernel file-backed mount controversy) although I know there are many use cases.

@alexlarsson
Copy link
Collaborator

alexlarsson commented Sep 30, 2024

Yeah, what would be very good is if EROFS, when using the file-backed mounts could take an optional fs-verity digest mount option, and do the validation of it in the kernel. Then it could somehow mark the mount with a "on fs-verity" flag. And then further, overlayfs could, if all layers except data only layers are marked "on fs-verity" and veryity=enabled is used, then it could also set the "on fs-verity" flag.

Then one could use this flag with something like IPE.

However, this is just the "fs-verity" part, we also would need to propagate the fact that the initial mountpoint was signed, and that seems much more tricky.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants