On Wed, Jun 08, 2022 at 12:01:25PM -0700, Deven Bowers wrote:
From: Fan Wu <wufan(a)linux.microsoft.com>
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(a)linux.microsoft.com>
Signed-off-by: Deven Bowers <deven.desai(a)linux.microsoft.com>
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