Re: [PATCH RFC 1/4] ipe: add the .ipe policy keyring

[luca.boccassi@gmail.com]

On Thu, 2026-10-22 at 13:18 -0400, Paul Moore wrote:
> On Thu, Oct 22, 2026 at 6:19 AM Christian Brauner
> <brauner@kernel.org> wrote:
> > On Wed, Oct 21, 2026 at 12:51:35PM -0400, Paul Moore wrote:
> > 
> 
> ...
> 
> > 
> > > Of course, fitting in with existing norms is important,
> > > but if it causes IPE or existing IPE uses a lot of pain, that can
> > > a
> > > good reason to diverge from those solutions.
> > 
> > Which pain?
> 
> As I said before, (emphasis now added for claification) "... *if* it
> causes IPE or existing IPE uses a lot of pain ...".  I intentionally
> did not make a claim either way.  Once again, I wanted to provide Fan
> some support in case there was an issue and he found himself in a
> position where he had to push back to preserve IPE's model.

I think there is one issue with the design pattern where keyrings are
set up in userspace, that I have mentioned a few times already and I
got documented in
https://www.freedesktop.org/software/systemd/man/latest/systemd-system.conf.html#RestrictFileSystemAccess=
as well: they are trivially bypassable if the kernel has kexec enabled
and it is signed. The security model relies on the "good" userspace
running first, but if kexec is enabled, there's no guarantee that will
be the case, and as far as I can tell it gives root trivial capability
of overriding it and extending the trust chain as the attacker wishes.

IPE specifically was designed to avoid exactly that, and ensure
userspace could not execute untrusted code, even with root privileges.
With this enabled by default, userspace can just load the same signed
kernel image, passing in compromised initrd and command line, and gain
arbitrary code execution on the host, since only the kernel binary
itself is verified, and anything goes for the rest of the kexec
parameters.

This is of course not to say this new IPE keyring shouldn't be added.
But perhaps it would be nicer if the default build flag was mutually
exclusive with kexec being enabled? Not sure if that can be expressed
in Kconfig though? default: yes-if-kexec-off, no-if-kexec-on

At the very least IMHO this relationship should be documented
explicitly in the kconfig blurb, as it seems to me it's a major footgun
to leave laying around, and users might not necessarily be aware of it.