linux-kernel - Re: [PATCH v5 0/5] Lazy flush for the auth session

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]

Message-ID: <e70c55c6edea2a5be7786ee04a85778193237444.camel@kernel.org>
Date: Sat, 12 Oct 2024 13:56:07 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Roberto Sassu <roberto.sassu@...weicloud.com>, 
	linux-integrity@...r.kernel.org
Cc: James.Bottomley@...senPartnership.com, roberto.sassu@...wei.com, 
 mapengyu@...il.com, Mimi Zohar <zohar@...ux.ibm.com>, David Howells
 <dhowells@...hat.com>, Paul Moore <paul@...l-moore.com>, James Morris
 <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, Peter Huewe
 <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>,
 keyrings@...r.kernel.org,  linux-security-module@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 0/5] Lazy flush for the auth session

On Fri, 2024-10-11 at 19:25 +0300, Jarkko Sakkinen wrote:
> On Fri, 2024-10-11 at 18:10 +0200, Roberto Sassu wrote:
> > Initially, I thought that maybe it would not be good to have an
> > event
> > log with unmodified and altered measurement entries. Then, I tried
> > to
> > think if we can really prevent an active interposer from injecting
> > arbitrary PCR extends and pretending that those events actually
> > happened.
> > 
> > If I understood James's cover letter correctly, the kernel can
> > detect
> > whether a TPM reset occurred, but not that a PCR extend occurred
> > (maybe
> > with a shadow PCR?).
> 
> We can detect TPM reset indirectly. I.e. null seed re-randomizes
> per reset.
> 
> > 
> > Second point, do we really want to take the responsibility to
> > disable
> > the protection on behalf of users? Maybe a better choice is to let
> > them
> > consciously disable HMAC protection.
> 
> So when IMA is not used already with these fixes we get good
> results. And for tpm2_get_random() we can make the algorithm
> smarter. All in all we have good path ongoing for "desktop
> use case" that I would keep thing way there are or at least
> postpone any major decisions just a bit.
> 
> For server/IMA use case I'll add a boot parameter it can be
> either on or off by default, I will state that in the commit
> message and we'll go from there.

Up until legit fixes are place distributors can easily disable
the feature. It would be worse if TCG_TPM2_HMAC did not exist.

So I think it is better to focus on doing right things right,
since the feature itself is useful objectively, and make sure
that those fixes bring the wanted results.

BR, Jarkko