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: <85f25b5f-cbf0-4032-9502-5fa0f7d07849@huaweicloud.com>
Date: Sun, 15 Sep 2024 12:51:39 +0200
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, 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
Subject: Re: [PATCH v3 00/14] KEYS: Add support for PGP keys and signatures

On 9/15/2024 9:11 AM, Linus Torvalds wrote:
> On Fri, 13 Sept 2024 at 10:30, Roberto Sassu

[...]

> The objections I had were against the whole "start doing policy in
> kernel", with what sounded like actually parsing and unpacking rpm
> contents and verifying them with a pgp key. *That* still sounds like a
> disaster to me, and is the part that made me go "why isn't that done
> in user space together with then generating the fsverifty
> information"?

In my opinion, trusting root in this situation is not ideal. Trusting 
root means trusting all applications that root can run, that they will 
verify PGP signatures of fsverity digests with Linux distribution keys. 
In order to trust them, we would need to check the integrity of all 
those applications, in particular file read and IPC with the rest of the 
system.

A safer way to achieve the same goal is to let the kernel verify PGP 
signatures, assuming that the kernel is more privileged and cannot be 
tampered by root (for example, by using the 'lockdown' LSM). Since the 
PGP keys of the Linux distribution would be embedded in the kernel image 
(or certified by the embedded ones), trusting the system would require 
only to verify the kernel image itself (for example, with the boot loader).

Kernel-based policy enforcement is currently adopted by other LSMs, such 
as SELinux. SELinux also parses and enforces a policy sent from user 
space in the kernel. This does not mean that the policy itself is in the 
kernel, but that the kernel is the only component in the position of 
enforcing the policy without trusting all applications that root can run.

Roberto

> The argument that the kernel is the only part of the system you trust
> is bogus. The kernel does nothing on its own (apart from device
> enumeration etc of course), so if you have no trustworthy user space,
> then you might as well just give up entirely. At a *minimum* you have
> initrd, and that can then be the start of a chain of user space trust.
> 
> Parsing rpm files in the kernel really sounds horrendous. But that
> doesn't mean that I hate *this* series that just adds pgp key handling
> in case there are other valid uses for it.
> 
> But maybe I misunderstood the original suggestion from Roberto.
> 
>                Linus