Re: [PATCH v7 10/10] ipe: Add BPF program load policy enforcement via Hornet integration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `IPE_PROP_BPF_KERNEL_FALSE` property evaluates to `true` when `CONFIG_IPE_PROP_BPF_SIGNATURE` is disabled, violating IPE's fail-closed design.
- [High] `ipe_bpf_prog_load_post_integrity()` completely ignores the `lsmid` parameter, allowing other LSMs to silently overwrite Hornet's integrity verdict.
- [Medium] The documentation provides an insecure policy example that allows unprivileged users to bypass the `bpf_signature=OK` check using their own keyrings.
--

commit 341207097f16b88e2b641d2d93566b204484bce3
Author: Blaise Boscaccy <bboscaccy@linux.microsoft.com>

ipe: Add BPF program load policy enforcement via Hornet integration

Add support for the bpf_prog_load_post_integrity LSM hook, enabling IPE
to make policy decisions about BPF program loading based on integrity
verdicts provided by the Hornet LSM.

> diff --git a/Documentation/admin-guide/LSM/ipe.rst b/Documentation/admin-guide/LSM/ipe.rst
> index a756d81585317..d68ba9d98859e 100644
> --- a/Documentation/admin-guide/LSM/ipe.rst
> +++ b/Documentation/admin-guide/LSM/ipe.rst
[ ... ]
> @@ -788,6 +896,58 @@ Allow execution of a specific fs-verity file
>  
>     op=EXECUTE fsverity_digest=sha256:fd88f2b8824e197f850bf4c5109bea5cf0ee38104f710843bb72da796ba5af9e action=ALLOW
>  
> +Allow only signed BPF programs
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +::
> +
> +   policy_name=Allow_Signed_BPF policy_version=0.0.0
> +   DEFAULT action=ALLOW
> +
> +   DEFAULT op=BPF_PROG_LOAD action=DENY
> +   op=BPF_PROG_LOAD bpf_kernel=TRUE action=ALLOW
> +   op=BPF_PROG_LOAD bpf_signature=OK action=ALLOW

Since Hornet verifies the program signature against the user-provided
keyring ID, could an unprivileged user bypass this policy by creating a
personal user keyring, signing a malicious BPF program with their own key,
and passing their keyring ID?

Would it be better to recommend explicitly restricting the bpf_keyring
property in this example, perhaps to bpf_keyring=BUILTIN?

[ ... ]
> diff --git a/security/ipe/eval.c b/security/ipe/eval.c
> index 21439c5be3364..705c4ecfda696 100644
> --- a/security/ipe/eval.c
> +++ b/security/ipe/eval.c
[ ... ]
> @@ -297,6 +362,32 @@ static bool evaluate_property(const struct ipe_eval_ctx *const ctx,
[ ... ]
> +	case IPE_PROP_BPF_KERNEL_FALSE:
> +		return !evaluate_bpf_kernel(ctx);

When CONFIG_IPE_PROP_BPF_SIGNATURE is disabled, the stub for
evaluate_bpf_kernel() unconditionally returns false:

    static bool evaluate_bpf_kernel(const struct ipe_eval_ctx *const ctx)
    {
        return false;
    }

This causes !evaluate_bpf_kernel(ctx) to return true.

Does this inadvertently cause any IPE policy rule using bpf_kernel=FALSE
to always match when the feature is disabled? Should this regression be
addressed with a dedicated stub that returns false when disabled to maintain
the fail-closed design?

[ ... ]
> diff --git a/security/ipe/hooks.c b/security/ipe/hooks.c
> index 0ae54a880405a..9271e129a2cf2 100644
> --- a/security/ipe/hooks.c
> +++ b/security/ipe/hooks.c
[ ... ]
> +#ifdef CONFIG_IPE_PROP_BPF_SIGNATURE
> +/**
> + * ipe_bpf_prog_load_post_integrity() - Store integrity verdict in per-prog blob.
[ ... ]
> + */
> +int ipe_bpf_prog_load_post_integrity(struct bpf_prog *prog,
> +				     union bpf_attr *attr,
> +				     struct bpf_token *token,
> +				     bool kernel,
> +				     const struct lsm_id *lsmid,
> +				     enum lsm_integrity_verdict verdict)
> +{
> +	struct ipe_bpf_prog *blob = ipe_bpf_prog(prog);
> +
> +	blob->verdict = verdict;

Should this check the lsmid parameter before storing the verdict?

In a multi-LSM environment, it looks like any other integrity provider
calling this hook could silently overwrite the verdict previously set by
Hornet, potentially replacing an LSM_INT_VERDICT_BADSIG verdict with an
LSM_INT_VERDICT_OK or LSM_INT_VERDICT_NONE verdict.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260507191416.2984054-1-bboscaccy@linux.microsoft.com?part=10