On Wed, Jun 08, 2022 at 12:01:25PM -0700, Deven Bowers wrote: > From: Fan Wu <wufan@xxxxxxxxxxxxxxxxxxx> > > fsverity represents a mechanism to support both integrity and > authenticity protection of a file, supporting both signed and unsigned > digests. > > An LSM which controls access to a resource based on authenticity and > integrity of said resource, can then use this data to make an informed > decision on the authorization (provided by the LSM's policy) of said > claim. > > This effectively allows the extension of a policy enforcement layer in > LSM for fsverity, allowing for more granular control of how a > particular authenticity claim can be used. For example, "all (built-in) > signed fsverity files should be allowed to execute, but only these > hashes are allowed to be loaded as kernel modules". > > This enforcement must be done in kernel space, as a userspace only > solution would fail a simple litmus test: Download a self-contained > malicious binary that never touches the userspace stack. This > binary would still be able to execute. > > Signed-off-by: Fan Wu <wufan@xxxxxxxxxxxxxxxxxxx> > Signed-off-by: Deven Bowers <deven.desai@xxxxxxxxxxxxxxxxxxx> The IMA support for fs-verity, which is now upstream, already does this (except that IMA isn't an LSM). It also doesn't rely on the fs-verity builtin signatures, which shouldn't really be used. Can you elaborate on how what you're doing is better? - Eric -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
