[RFC PATCH v14 15/19] fsverity: consume builtin signature via LSM hook

[Paul Moore]

On Mon, Mar 11, 2024 at 11:07 PM Eric Biggers <ebiggers at kernel.org> wrote:
> On Mon, Mar 11, 2024 at 07:57:12PM -0700, Eric Biggers wrote:
> >
> > As I've said before, this commit message needs some work.  It currently doesn't
> > say anything about what the patch actually does.
> >
> > BTW, please make sure you're Cc'ing the fsverity mailing list
> > (fsverity at lists.linux.dev), not fscrypt (linux-fscrypt at vger.kernel.org).
>
> Also, I thought this patch was using a new LSM hook, but I now see that you're
> actually abusing the existing security_inode_setsecurity() LSM hook.  Currently
> that hook is called when an xattr is set.  I don't see any precedent for
> overloading it for other purposes.

I'm not really bothered by this, and if it proves to be a problem in
the future we can swap it for a new hook; we don't include the LSM
in-kernel API in any stable API guarantees.

> This seems problematic, as it means that a
> request to set an xattr with the name you chose ("fsverity.builtin-sig") will be
> interpreted by LSMs as the fsverity builtin signature.  A dedicated LSM hook may
> be necessary to avoid issues with overloading the existing xattr hook like this.

Would you be more comfortable if the name was in an IPE related space,
for example something like "ipe.fsverity-sig"?

-- 
paul-moore.com