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

[Christian Brauner <brauner@kernel.org>]

On Thu, Oct 22, 2026 at 01:25:36PM -0700, Fan Wu wrote:
> Also, one thing I missed earlier: before the policy verification call,
> please also check:
>
> ipe_keyring->restrict_link->check == restrict_link_reject
>
> so we make sure the restriction function is the right one.

I would advise against this. I'll explain why. Which restriction goes
onto the keyring is intentionally userspace's policy. The two supported
ones are:

    keyctl restrict_keyring $id

seals the keyring for good. Nothing can ever be added again. And

    keyctl restrict_keyring $id asymmetric key_or_keyring:0:chain

only allows certificates that are signed by a key that is already in
the keyring.

This allows userspace to enroll a vendor CA during boot and let
per-image certificates that chain to it be added later after the trusted
phase.

systemd-keyring-setup uses that second form for .dm-verity, .fs-verity
and .bpf and then drops KEY_USR_SETATTR, so neither the restriction nor
the permission mask can be changed anymore while root keeps write
permission to enroll chained certificates.

Both are proper seals. A restriction can only be set once as afterwards
keyring_restrict() returns -EEXIST. So there is no way to remove it.

So whoever restricts the keyring is the provisioner and whatever they
pick is the policy. A random root process after the seal can't extend
the set of trust anchors either way. With the chain restriction it needs
a signature from a key that is already trusted.

That's why .dm-verity and .bpf only test that restrict_link is set.
"Restricted" is the state the kernel knows about. The policy belongs to
userspace.

So it would be really nice if we could've the same behavior for all
these keyrings. I think that this is a really nice model and allows
userspace to have a kernel enforced policy.

Christian