linux-kernel - Re: [PATCH v3 00/14] KEYS: Add support for PGP keys and signatures

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: <20240917112724.GA14167@wind.enjellic.com>
Date: Tue, 17 Sep 2024 06:27:24 -0500
From: "Dr. Greg" <greg@...ellic.com>
To: Roberto Sassu <roberto.sassu@...weicloud.com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
        Linus Torvalds <torvalds@...ux-foundation.org>, dhowells@...hat.com,
        dwmw2@...radead.org, davem@...emloft.net, linux-kernel@...r.kernel.org,
        keyrings@...r.kernel.org, linux-crypto@...r.kernel.org,
        zohar@...ux.ibm.com, linux-integrity@...r.kernel.org,
        roberto.sassu@...wei.com, linux-security-module@...r.kernel.org,
        Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH v3 00/14] KEYS: Add support for PGP keys and signatures

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.sassu@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.camel@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