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

[sashiko-bot@kernel.org]

Sashiko AI review found 3 potential issue(s):
- [Low] Build failure when CONFIG_IPE_PROP_BPF_SIGNATURE is disabled due to unconditional access to a conditionally compiled field.
- [Low] The commit message provides an incorrect property name in the example policy.
- [Low] The example policy in the commit message may be insecure depending on the integrity provider's keyring semantics.
--

commit 81e945a1fa4e8ba5734149eaa67ab6ab459e3ad6
Author: Blaise Boscaccy <bboscaccy@linux.microsoft.com>

ipe: Add BPF program load policy enforcement via Hornet integration

This commit adds 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.

>     Example policy for bpf signature enforcement:
>      DEFAULT op=BPF_PROG_LOAD action=DENY
>      op=BPF_PROG_LOAD is_kernel=TRUE action=ALLOW

This isn't a bug in the code, but there appears to be a typo in the example
policy. Should is_kernel=TRUE be bpf_kernel=TRUE to match the property defined
in the property_tokens array?

>      op=BPF_PROG_LOAD bpf_signature=OK action=ALLOW

Also in the example policy, is it safe to use bpf_signature=OK without a
keyring restriction like bpf_keyring=BUILTIN?

If the underlying LSM validates signatures against user-provided keyrings,
could an attacker bypass the policy by signing a malicious BPF program with
their own key?

> diff --git a/security/ipe/eval.c b/security/ipe/eval.c
> index 21439c5be3364..9a6d583fea125 100644
> --- a/security/ipe/eval.c
> +++ b/security/ipe/eval.c

[ ... ]

> @@ -297,6 +342,32 @@ static bool evaluate_property(const struct ipe_eval_ctx *const ctx,

[ ... ]

> +	case IPE_PROP_BPF_KERNEL_FALSE:
> +		return !ctx->bpf_kernel;
> +	case IPE_PROP_BPF_KERNEL_TRUE:
> +		return ctx->bpf_kernel;
>  	default:

If CONFIG_IPE_PROP_BPF_SIGNATURE is disabled, will this cause a build failure?

The bpf_kernel field in struct ipe_eval_ctx is only defined within an
ifdef CONFIG_IPE_PROP_BPF_SIGNATURE block.

Could this access be abstracted through a helper function with a fallback
stub like evaluate_bpf_sig()?

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