On Fri, 2024-09-13 at 12:45 +0800, Herbert Xu wrote: > Roberto Sassu <roberto.sa...@huaweicloud.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.ca...@huaweicloud.com/ Please, keep in mind that I already proposed what you suggested: https://lore.kernel.org/linux-kernel/20230317145240.363908-1-roberto.sa...@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,
