On 11/3/2021 5:28 AM, Roberto Sassu wrote:
From: Deven Bowers [mailto:deven.desai@xxxxxxxxxxxxxxxxxxx]
Sent: Friday, October 15, 2021 9:26 PM
On 10/13/2021 12:24 PM, Eric Biggers wrote:
On Wed, Oct 13, 2021 at 12:06:31PM -0700,
deven.desai@xxxxxxxxxxxxxxxxxxx wrote:
From: Fan Wu <wufan@xxxxxxxxxxxxxxxxxxx>
Add security_inode_setsecurity to fsverity signature verification.
This can let LSMs save the signature data and digest hashes provided
by fsverity.
Can you elaborate on why LSMs need this information?
The proposed LSM (IPE) of this series will be the only one to need
this information at the moment. IPE’s goal is to have provide
trust-based access control. Trust and Integrity are tied together,
as you cannot prove trust without proving integrity.
I wanted to go back on this question.
It seems, at least for fsverity, that you could obtain the
root digest at run-time, without storing it in a security blob.
I thought I should use fsverity_get_info() but the fsverity_info
structure is not exported (it is defined in fs/verity/fsverity_private.h).
Then, I defined a new function, fsverity_get_file_digest() to copy
the file_digest member of fsverity_info to a buffer and to pass
the associated hash algorithm.
With that, the code of evaluate() for DIGLIM becomes:
info = fsverity_get_info(file_inode(ctx->file));
if (info)
ret = fsverity_get_file_digest(info, buffer, sizeof(buffer), &algo);
if (!strcmp(expect->data, "diglim") && ret > 0) {
ret = diglim_digest_get_info(buffer, algo, COMPACT_FILE, &modifiers, &actions);
if (!ret)
return true;
}
This would work with the digest with a bit more code in fs-verity. It
also has benefits if there are other callers who want this information.
I was planning on grouping the digest and signature into
apublic_key_signature
structure in v8 to pass the digest, digest algorithm,digest size, signature
and signature size (as opposed to defining a new structfor this purpose),
reducing the number of LSM hook calls down to one functionin fsverity.
I think both approaches have merit. fsverity_get_file_digest is more useful
if there are callers outside of LSMs that want this information. The LSM
hook
is cleaner if only LSMs want this information.
At least, at the moment, it seems like it's only IPE who wants this
information,
and it's not like it won't be able to change later if the need arises,
as this
is all implementation details that wouldn't effect the end-user.
I'll defer to Eric - his opinion holds the most weight, as fsverity would be
the main code affected in either case.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
