On Mon, May 19, 2025 at 3:20 PM KP Singh kpsingh@kernel.org wrote:
On Sun, May 18, 2025 at 11:34 PM Paul Moore paul@paul-moore.com wrote:
On Sun, May 18, 2025 at 11:52 AM Alexei Starovoitov alexei.starovoitov@gmail.com wrote:
On Sat, May 17, 2025 at 10:49 PM Paul Moore paul@paul-moore.com wrote:
On May 17, 2025 12:13:50 PM Alexei Starovoitov alexei.starovoitov@gmail.com wrote:
On Sat, May 17, 2025 at 8:03 AM Paul Moore paul@paul-moore.com wrote:
On Fri, May 16, 2025 at 7:49 PM Alexei Starovoitov alexei.starovoitov@gmail.com wrote: > On Fri, May 16, 2025 at 12:49 PM Paul Moore paul@paul-moore.com wrote: >> >> I think we need some clarification on a few of these details, it would >> be good if you could answer the questions below about the >> authorization aspects of your design? >> >> * Is the signature validation code in the BPF verifier *always* going >> to be enforced when a signature is passed in from userspace? In other >> words, in your design is there going to be either a kernel build time >> or runtime configuration knob that could selectively enable (or >> disable) signature verification in the BPF verifier? > > If there is a signature in union bpf_attr and it's incorrect > the prog_load command will be rejected. > No point in adding a knob to control that.
I agree that when a signature is provided and that signature check fails, the BPF load should be rejected. I'm simply trying to understand how you envision your design handling all of the cases, not just this one, as well as what build and runtime options you expect for controlling various aspects of this behavior.
>> * In the case where the signature validation code in the BPF verifier >> is active, what happens when a signature is *not* passed in from >> userspace? Will the BPF verifier allow the program load to take >> place? Will the load operation be blocked? Will the load operation >> be subject to a more granular policy, and if so, how do you plan to >> incorporate that policy decision into the BPF program load path? > > If there is no signature the existing loading semantics will remain intact. > We can discuss whether to add a sysctl or cgroup knob to disallow > loading when signature is not present ...
As mentioned earlier this week, if the BPF verifier is performing the signature verification as KP described, we will need a LSM hook after the verifier to serve as an access control point. Of course that doesn't preclude the addition of some type of sysctl/cgroup/whatever based access control, but the LSM hook would be needed regardless.
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.
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