On Sun, Sep 15, 2024 at 07:52:13PM +0200, Roberto Sassu wrote: Good morning, I hope the day is starting well for everyone.
> On 9/15/2024 11:31 AM, Herbert Xu wrote: > >On Sun, Sep 15, 2024 at 05:15:25PM +0800, Herbert Xu wrote: > >> > >>Roberto, correct me if I'm wrong but your intended use case is > >>the following patch series, right? > > > >Actually the meat of the changes is in the following series: > > > >https://lore.kernel.org/linux-integrity/20240905150543.3766895-1-roberto.sa...@huaweicloud.com/ > Yes, correct. The idea is to verify the authenticity of RPM headers, > extract the file digests from them, and use those file digests as > reference values for integrity checking of files accessed by user > space processes. > > If the calculated digest of a file being accessed matches one > extracted from the RPM header, access is granted otherwise it is > denied. Based on the above response and your comment: "The security policy I want to enforce is: all code that the system executes has been built by a trusted source (e.g. a Linux distribution)." >From the following URL: https://lore.kernel.org/linux-integrity/b4a3e55650a9e9f2302cf093e5cc8e739b4ac98f.ca...@huaweicloud.com/#t What you are advocating for then, with this patch series and the digest cache series, is a security policy that requires signed code execution, correct? Nothing wrong with that, it is a reasonable security desire, but it seems wrong to conflate that with the implementation of the digest cache. There is a great deal of utility in a digest cache but it doesn't require the need to parse RPM header information and/or TLV sequences in the kernel. That would only appear to be a requirement if your goal is a signed executable policy that is implemented through a packaging medium, correct? To wit: If I have security infrastructure that gives me confidence in the integrity of the files on my media, I can populate a digest cache with a simple ASCII list of pathnames fed into the kernel at boot time. If I don't have confidence in the integrity of the files on my media I could append a known good checksum to each pathname with the last entry in the list being a PGP signature over the input stream. I brought the following issue up in the patch series that Herbert links to above, but will do so here, since I believe it has relevance to this conversation as well. If the goal is to have the digest cache be relevant from an integrity perspective, particularly a signed code policy, you have to physically read every file that has a digest value in the RPM digest list. Otherwise the scheme is vulnerable to a Time Of Measurement Time Of Use (TOMTOU) vulnerability scenario, correct? This requires that one needs to experience a latency hit at least once, presumably at boot when you prime the digest cache, correct? An alternative approach may be to separate the RPM/TLV parsing code from the digest code and implement RPM/Debian/whatever parsing in a loadable module that would in turn populate the digest cache. That may be a more acceptable strategy since it places the potential security vulnerabilities of a parser into something that an entity that is interested in a signed code policy would consider to be an acceptable tradeoff from a security perspective. > Roberto Hopefully the above comments and clarifications will be helpful in furthering additional discussion. Have a good day. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity https://github.com/Quixote-Project
