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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2026-10-27 at 11:07 +0000, Luca Boccassi wrote:
> On Mon, 26 Oct 2026 at 12:57, <luca.boccassi@gmail.com> wrote:
> > 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.

The attack sounds doable, but it also seems to be exploiting a gap in
kexec policy: kexec is supposed to behave like a warm reboot so if boot
policy requires UKI only then so should kexec and that sounds like the
thing that should be fixed.

What's the mechanism boot uses to ensure UKI only? So we can see if it
can be adopted to kexec.

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

Yes, but, it the above kexec policy problem were solved, IPE would just
work as expected, wouldn't it?  So this seems like a work around for a
kexec issue rather than a fundamental IPE need.

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

I wouldn't do this because a) I don't think it's an IPE problem, I
think it's a kexec one and b) distros get very tetchy about hard to
solve feature anti dependencies.

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

I'd document the need for trusted userspace on kexec if it was a boot
requirement, yes.

> KHO/keyring folks, what would you think about preserving sealed
> keyrings across kexec via KHO so that the chain of trust can't be
> reset by userspace? Good idea/bad idea/yes send patches/no go
> away/etc?

Well, yes, we do have a similar problem with the trusted keyrings. 
They're actually initialized from the shim created ..RT variables
(which are volatile, but don't die on kexec).  On first boot they're
initialized before user space, so we know they came from shim (or
another trusted component in the boot chain) but if root uses UEFI RT
services to add to a ..RT keyring, the added key will appear trusted
after kexec.

Regards,

James