linux-kernel - Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

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] [day] [month] [year] [list]

Message-ID: <ZxqmoV-izscjbovh@lei>
Date: Thu, 24 Oct 2024 19:57:21 +0000
From: sergeh@...nel.org
To: Eric Snowberg <eric.snowberg@...cle.com>
Cc: "open list:SECURITY SUBSYSTEM" <linux-security-module@...r.kernel.org>,
	David Howells <dhowells@...hat.com>,
	David Woodhouse <dwmw2@...radead.org>,
	"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
	"davem@...emloft.net" <davem@...emloft.net>,
	Ard Biesheuvel <ardb@...nel.org>,
	Jarkko Sakkinen <jarkko@...nel.org>,
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Mimi Zohar <zohar@...ux.ibm.com>,
	Roberto Sassu <roberto.sassu@...wei.com>,
	Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
	Mickaël Salaün <mic@...ikod.net>,
	"casey@...aufler-ca.com" <casey@...aufler-ca.com>,
	Stefan Berger <stefanb@...ux.ibm.com>,
	"ebiggers@...nel.org" <ebiggers@...nel.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	open list <linux-kernel@...r.kernel.org>,
	"keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
	"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>
Subject: Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

On Wed, Oct 23, 2024 at 07:25:21PM +0000, Eric Snowberg wrote:
> > On Oct 22, 2024, at 8:25 PM, sergeh@...nel.org wrote:
> > 
> > On Thu, Oct 17, 2024 at 09:55:11AM -0600, Eric Snowberg wrote:
> >> 
> >> +The Clavis LSM contains a system keyring call .clavis.  It contains a single
> > 
> > s/call/called/
> 
> I will change that, thanks.
> 
> >> +asymmetric key that is used to validate anything added to it.  This key can
> >> +be added during boot and must be a preexisting system kernel key.  If the
> >> +``clavis=`` boot parameter is not used, any asymmetric key the user owns
> > 
> > Who is "the user", and precisely what does "owns' mean here?  Is it just
> > restating that it must be a key already in one of the builtin or secondary
> > or platform keyrings?
> 
> In the case where Clavis was not provided a key id during boot, root can 
> add a single public key to the .clavis keyring anytime afterwards.  This 
> key does not need to be in any of the system keyrings.  Once the key is 
> added, the Clavis LSM is enabled. The root user must also own the private 
> key, since this is required to do the ACL signing. I will try to clarify this better 

Ooh, I see.  Own it as in be able to sign things with it.  Of course.  Thanks.

> in the documentation. 
> 
> I wouldn't expect this to be the typical way Clavis would be used. I would 

Right, I wasn't asking because I would want to use it that way, but
because it feels potentially dangerous :)

> also be interested in any feedback if enabling the Clavis LSM this way 
> following boot should be removed.  If this were removed, Clavis could 
> only be enabled when using the boot parameter.

Yeah I don't know enough to give good guidance here.  I do worry about
UKIs enforcing only the built-in signed kernel command line and so preventing
a user from appending their own clavis= entry.  Not knowing how this
will end up getting deployed, I'm not sure which is the more important
issue.

> > And this is done by simply loading it into the clavis keyring, right?
> 
> Correct.
>