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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 12 Mar 2024 09:12:05 -0400
From: Paul Moore <paul@...l-moore.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Fan Wu <wufan@...ux.microsoft.com>, corbet@....net, zohar@...ux.ibm.com, 
	jmorris@...ei.org, serge@...lyn.com, tytso@....edu, axboe@...nel.dk, 
	agk@...hat.com, snitzer@...nel.org, eparis@...hat.com, 
	linux-doc@...r.kernel.org, linux-integrity@...r.kernel.org, 
	linux-security-module@...r.kernel.org, linux-fscrypt@...r.kernel.org, 
	linux-block@...r.kernel.org, dm-devel@...ts.linux.dev, audit@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Deven Bowers <deven.desai@...ux.microsoft.com>
Subject: Re: [RFC PATCH v14 15/19] fsverity: consume builtin signature via LSM hook

On Mon, Mar 11, 2024 at 11:07 PM Eric Biggers <ebiggers@...nel.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@...ts.linux.dev), not fscrypt (linux-fscrypt@...r.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