Message-ID: <8b7d0c280ae51f619c0e57379824a858de463098.camel@huaweicloud.com>
Date: Wed, 27 Nov 2024 18:56:47 +0100
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: "Dr. Greg" <greg@...ellic.com>
Cc: zohar@...ux.ibm.com, dmitry.kasatkin@...il.com,
 eric.snowberg@...cle.com,  corbet@....net, mcgrof@...nel.org,
 petr.pavlu@...e.com, samitolvanen@...gle.com,  da.gomez@...sung.com,
 akpm@...ux-foundation.org, paul@...l-moore.com,  jmorris@...ei.org,
 serge@...lyn.com, shuah@...nel.org, mcoquelin.stm32@...il.com, 
 alexandre.torgue@...s.st.com, linux-integrity@...r.kernel.org, 
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
 linux-api@...r.kernel.org, linux-modules@...r.kernel.org, 
 linux-security-module@...r.kernel.org, linux-kselftest@...r.kernel.org, 
 wufan@...ux.microsoft.com, pbrobinson@...il.com, zbyszek@...waw.pl,
 hch@....de,  mjg59@...f.ucam.org, pmatilai@...hat.com, jannh@...gle.com,
 dhowells@...hat.com,  jikos@...nel.org, mkoutny@...e.com, ppavlu@...e.com,
 petr.vorel@...il.com,  mzerqung@...inter.de, kgold@...ux.ibm.com, Roberto
 Sassu <roberto.sassu@...wei.com>
Subject: Re: [PATCH v6 00/15] integrity: Introduce the Integrity Digest Cache

On Wed, 2024-11-27 at 11:30 -0600, Dr. Greg wrote:
> On Tue, Nov 19, 2024 at 11:49:07AM +0100, Roberto Sassu wrote:
> 
> Hi Roberto, I hope the week is going well for you.
> 
> > From: Roberto Sassu <roberto.sassu@...wei.com>
> > 
> > Integrity detection and protection has long been a desirable feature, to
> > reach a large user base and mitigate the risk of flaws in the software
> > and attacks.
> > 
> > However, while solutions exist, they struggle to reach a large user base,
> > due to requiring higher than desired constraints on performance,
> > flexibility and configurability, that only security conscious people are
> > willing to accept.
> > 
> > For example, IMA measurement requires the target platform to collect
> > integrity measurements, and to protect them with the TPM, which introduces
> > a noticeable overhead (up to 10x slower in a microbenchmark) on frequently
> > used system calls, like the open().
> > 
> > IMA Appraisal currently requires individual files to be signed and
> > verified, and Linux distributions to rebuild all packages to include file
> > signatures (this approach has been adopted from Fedora 39+). Like a TPM,
> > also signature verification introduces a significant overhead, especially
> > if it is used to check the integrity of many files.
> > 
> > This is where the new Integrity Digest Cache comes into play, it offers
> > additional support for new and existing integrity solutions, to make
> > them faster and easier to deploy.
> > 
> > The Integrity Digest Cache can help IMA to reduce the number of TPM
> > operations and to make them happen in a deterministic way. If IMA knows
> > that a file comes from a Linux distribution, it can measure files in a
> > different way: measure the list of digests coming from the distribution
> > (e.g. RPM package headers), and subsequently measure a file if it is not
> > found in that list.
> > 
> > The performance improvement comes at the cost of IMA not reporting which
> > files from installed packages were accessed, and in which temporal
> > sequence. This approach might not be suitable for all use cases.
> > 
> > The Integrity Digest Cache can also help IMA for appraisal. IMA can simply
> > lookup the calculated digest of an accessed file in the list of digests
> > extracted from package headers, after verifying the header signature. It is
> > sufficient to verify only one signature for all files in the package, as
> > opposed to verifying a signature for each file.
> 
> Roberto, a big picture question for you, our apologies if we
> completely misunderstand your patch series.

Hi Greg

no need to apologise, happy to answer your questions.

> The performance benefit comes from the fact that the kernel doesn't
> have to read a file and calculate the cryptographic digest when the
> file is accessed.  The 'trusted' digest value comes from a signed list
> of digests that a packaging entity provides and the kernel validates.
> So there is an integrity guarantee that the supplied digests were the
> same as when the package was built.

The performance benefit (for appraisal with my benchmark: 65% with
sequential file access and 43% with parallel file access) comes from
verifying the ECDSA signature of 303 digest lists, as opposed to the
ECDSA signature of 12312 files.

The additional performance boost due to switching from file data digest
to fsverity digests is on top of that.

> Is there a guarantee implemented, that we missed, that the on-disk
> file actually has the digest value that was initially generated by the
> packaging entity when the file is accessed operationally?

Yes, the guarantee is provided by IMA by measuring the actual file
digest and searching it in a digest cache. The integration in IMA of
the Integrity Digest Cache is done in a separate patch set:

https://lore.kernel.org/linux-security-module/20241119110103.2780453-1-roberto.sassu@huaweicloud.com/

The integrity evaluation result is invalidated when the file is
modified, or when the digest list used to verify the file is modified
too.

For fsverity, the guarantee similarly comes from searching the fsverity
digest in a digest cache, but as opposed of IMA the integrity
evaluation result does not need to be invalidated for a file write,
since fsverity-protected files are accessible only in read-only mode.
However, the result still needs to be invalidated if the digest list
changes.

> Secondly, and in a related issue, what happens in a container
> environment when a pathname is accessed that is actually a different
> file but with the same effective pathname as a file that is in the
> vendor validated digest list?

At the moment nothing, only the file data are evaluated. Currently, the
Integrity Digest Cache does not store the pathnames associated to a
digest. It can be done as an extension, if desired, and the pathnames
can be compared.

Roberto

> Once again, apologies, if we completely misinterpret the issues
> involved.
> 
> Have a good remainder of the week.
> 
> As always,
> Dr. Greg
> 
> The Quixote Project - Flailing at the Travails of Cybersecurity
>               https://github.com/Quixote-Project

Powered by blists - more mailing lists