linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	dhowells@redhat.com, dwmw2@infradead.org, davem@davemloft.net,
	linux-kernel@vger.kernel.org, keyrings@vger.kernel.org,
	linux-crypto@vger.kernel.org, zohar@linux.ibm.com,
	linux-integrity@vger.kernel.org, roberto.sassu@huawei.com,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH v3 00/14] KEYS: Add support for PGP keys and signatures
Date: Sun, 15 Sep 2024 12:51:39 +0200	[thread overview]
Message-ID: <85f25b5f-cbf0-4032-9502-5fa0f7d07849@huaweicloud.com> (raw)
In-Reply-To: <CAHk-=wiU24MGO7LZ1ZZYpQJr1+CSFG9VnB0Nyy4xZSSc_Zu0rg@mail.gmail.com>

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


      parent reply	other threads:[~2024-09-15 10:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ZuPDZL_EIoS60L1a@gondor.apana.org.au>
2024-09-13  8:30 ` [PATCH v3 00/14] KEYS: Add support for PGP keys and signatures Roberto Sassu
2024-09-13  9:00   ` Herbert Xu
2024-09-15  7:11   ` Linus Torvalds
2024-09-15  8:07     ` Herbert Xu
2024-09-15  8:40       ` Linus Torvalds
2024-09-15  9:15         ` Herbert Xu
2024-09-15  9:31           ` Herbert Xu
2024-09-15 17:52             ` Roberto Sassu
2024-09-17 11:27               ` Dr. Greg
2024-09-26  9:41         ` Roberto Sassu
2024-09-27  1:25           ` Dr. Greg
2024-10-04 10:42           ` Roberto Sassu
2024-09-15 10:51     ` Roberto Sassu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85f25b5f-cbf0-4032-9502-5fa0f7d07849@huaweicloud.com \
    --to=roberto.sassu@huaweicloud.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=roberto.sassu@huawei.com \
    --cc=torvalds@linux-foundation.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).