linux-kernel - Re: [RFC PATCH v3 00/13] Clavis LSM

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 for Android: free password hash cracker in your pocket

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

Message-ID: <A8EE4069-D797-4792-BD82-D7F34BCD885F@oracle.com>
Date: Mon, 24 Mar 2025 17:44:27 +0000
From: Eric Snowberg <eric.snowberg@...cle.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>
CC: Paul Moore <paul@...l-moore.com>, Mimi Zohar <zohar@...ux.ibm.com>,
        David
 Howells <dhowells@...hat.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        "open
 list:SECURITY SUBSYSTEM" <linux-security-module@...r.kernel.org>,
        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>, James Morris <jmorris@...ei.org>,
        "Serge E.
 Hallyn" <serge@...lyn.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 00/13] Clavis LSM



> On Mar 21, 2025, at 2:53 PM, James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> 
> On Fri, 2025-03-21 at 20:15 +0000, Eric Snowberg wrote:
>>> On Mar 21, 2025, at 10:55 AM, James Bottomley
>>> <James.Bottomley@...senPartnership.com> wrote:
> [...]
>>>>   Hopefully that is not the case, since the public  key ships on
>>>> just about every single PC built.
>>> 
>>> I don't understand why Microsoft no-longer owning the private key
>>> is a problem?  Only the public key ships on PCs and that hasn't
>>> changed (at least not yet, it might have to for NIST requirements
>>> since RSA2048 is being deprecated).
>> 
>> A couple concerns come to mind.  First, the vetting process being
>> done for individuals that have signing authority with the HSM outside
>> of Microsoft.
> 
> I'm not aware UEFI has published any information on this.  I think the
> shim-review repo predates UEFI ownership, but I'm sure the maintainers
> of the repository can answer how they came to be trusted ...

Thanks for clarifying, I didn’t realize there were copies of the private key 
outside of Microsoft.

>> Another would be access control of the HSM.  Especially if it is not
>> within Microsoft's possession.
> 
> ... and how they handle the HSM.
> 
> However, if you're worried about risks to the integrity of secure boot,
> I'd be much more concerned about the number of ODM motherboard
> manufacturers who seem to have managed to lose their PK private keys,
> or keys they placed into db, somehow ...

That’s precisely the protection Clavis offers. It begins immediately after 
ExitBootServices and continues through all kexecs. Once the kernel starts, 
the end-user is in control of all system kernel keys.  Obviously some type 
of precaution must be taken to get into the first kernel.  The Clavis key 
belongs to the end-user, and they have the freedom to determine which 
kernel keys perform specific tasks within the system. This level of protection 
wouldn’t be feasible with the proposed named kernel keyring approach.  
With the named kernel keyring approach, it could be defeated with kexec.
When you have hardware vendors shipping systems in the past with test/demo 
DB/KEK/PK keys, or other companies that allow their signing key to be used 
by others, this level of protection is sought after by some users.