No. New hook is not needed.
[...]
It would be good for you to explain how the existing LSM hook is sufficient to authorize the loading of a BPF program using the signature validation state determined in the BPF verifier.
I already explained: .. a job of trivial LSM: if (prog_attr doesn't have signature && (task == .. || task is under certain cgroup || whatever)) disallow.
I read that earlier reply as an example that covers a sample use case, I didn't realize you were asserting that was the only approach you were considering. Perhaps that was the source of confusion earlier, we may disagree, but I don't intentionally "twist" words; not only is that rude, it's just stupid in public, archived discussions.
As I mentioned previously, we really need to see an explicit yes/no flag from the BPF verifier to indicate that the signature on the BPF program has been validated. It really should be as simple as adding a bool to bpf_prog_aux which the BPF verifier sets to true upon successful signature validation, and then an LSM can use this flag as input to an access control decision in a hook placed after the verifier. Are you objecting to the addition of a flag in the bpf_prog_aux struct (or some other struct tightly coupled to the BPF program), the LSM hook after the verifier, or both? It would also be helpful if you can elaborate on the technical reasons behind these objections.
Neither the aux field, nor the hook are required because:
- If the signature is passed, it will be enforced, there are no
"runtime aspects" that need to be configurable here.
- What the LSM can specify a policy for is when a signature is not
passed, for this, it does not need an aux field or a signature or the new hook, existing hooks are sufficient.
What about wanting to create a policy that requires signatures under certain situations and allowing the lack of a signature under others? How is that implemented with the existing hooks? As I understand it, all the existing hooks know (would know) is that _if_ there is a signature _then_ it will be enforced. There is no way to know _whether_ there is a signature.
The signature is passed in bpf_attr and if there is a signature the LSM's job is done.
https://elixir.bootlin.com/linux/v6.14.7/source/kernel/bpf/syscall.c#L5771
It will be enforced.
- KP
An example policy I can think of is that most users (with CAP_BPF) must submit signed programs but some users are exempted. Would that policy be able to be made with the current hooks?
- KP
-- paul-moore.com