Message-ID: <b4a3e55650a9e9f2302cf093e5cc8e739b4ac98f.camel@huaweicloud.com>
Date: Fri, 13 Sep 2024 10:30:11 +0200
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: 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, torvalds@...ux-foundation.org, 
	roberto.sassu@...wei.com, linux-security-module@...r.kernel.org
Subject: Re: [PATCH v3 00/14] KEYS: Add support for PGP keys and signatures

On Fri, 2024-09-13 at 12:45 +0800, Herbert Xu wrote:
> Roberto Sassu <roberto.sassu@...weicloud.com> wrote:

+ linux-security-module

> > 
> > For the envisioned use cases, PGP operations cannot be done in user space,
> > since the consumers are in the kernel itself (Integrity Digest Cache and
> > IMA). Also they cannot be done in a trusted initial ram disk, since PGP
> > operations can occur also while the system is running (e.g. after software
> > package installation).
> 
> Does this address Linus's objections? If not then we cannot proceed.

I hope to get an answer from him.

> Personally I don't think the argument above holds water.  With
> IPsec we had a similar issue of authenticating untrusted peers
> using public key cryptography.  In that case we successfully
> delegated the task to user-space and it is still how it works
> to this day.

That makes sense, since it is not the kernel holding secrets on behalf
of user space, it is user space passing the crypto material to the
kernel (if I remember IPSEC correctly). Failure of user space to hold
its secrets or to tamper with the task has only effect in user space.

With my understanding, I'm citing a source enumerating the requirements
of a secure system:

James P. Anderson: Computer Security Technology Planning Study

The first requirement of a component enforcing a security policy on a
Target of Evaluation (TOE), aka the reference monitor, is that it must
be tamperproof [1].

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).

I want to leverage the kernel to enforce such security policy, and I
assume that the kernel can be fortified enough (for example through the
lockdown LSM) to be considered tamperproof against the TOE (the user
space processes).

The first problem I see in delegating the public crypto task to user
space is that it is at the same time part of the reference monitor
(since it is used to enforce the security policy) and it is a TOE too.

The second problem is, assuming that the task is verified through other
means other than PGP (but again, we are still relying on the public
crypto functionality to be performed by the kernel, for this to work),
that I didn't get a confirmation that user space can have equivalent
isolation guarantees as the kernel:

https://lore.kernel.org/linux-integrity/eb31920bd00e2c921b0aa6ebed8745cb0130b0e1.camel@huaweicloud.com/


Please, keep in mind that I already proposed what you suggested:

https://lore.kernel.org/linux-kernel/20230317145240.363908-1-roberto.sassu@huaweicloud.com/#r


After discussing with some kernel developers, the outcome was that a
better choice would be to put the code in the kernel, if I want
reasonable tamperproof guarantees.

Thanks

Roberto


[1] https://seclab.cs.ucdavis.edu/projects/history/papers/ande72a.pdf (page 17)

> A user-space daemon dedicated to public key crypto seems equally
> applicable to your scenario.
> 
> The original application that brought public key crypto into the
> kernel was module loading.  If we really wanted to we could extend
> the user-space verification to modules too and perhaps kick all
> public key crypto out of the kernel.
> 
> The complexity and lack of reviewer attention in this area means
> that we're more likely to introduce security holes into the kernel
> with such code.
> 
> Cheers,

Powered by blists - more mailing lists