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@huawei.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.
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.
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?
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?
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