On Thu, Dec 19, 2019 at 05:05:42PM +0000, Edwin Peer wrote: > On 12/19/19, 07:47, "Daniel Borkmann" <daniel@xxxxxxxxxxxxx> wrote: > > > What about CAP_BPF? > > What is the status of this? It might solve some of the problems, but it is still puts testing > BPF outside reach of normal users. why? I think CAP_BPF is solving exactly what you're trying to achieve. Use CAP_BPF to load _any_ program type and use prog_test_run to run it. While discussing CAP_BPF during plumbers conf we realized that the kernel doesn't need to check CAP_BPF for prog_test_run. It's user supplied data. No security risk. Though the kernel needs to make sure that dangerous helpers are not used for prog_test_run. Whether bpf_clone_redirect() is such helper is still tbd. Unpriv user can flood netdevs without any bpf. > > IIRC, there are also other issues e.g. you could abuse the test interface as a packet > > generator (bpf_clone_redirect) which is not something fully unpriv should be doing. > > Good point. I suspect solutions exist - I'm trying to ascertain if they are worth pursuing > or if the idea of unprivileged testing is a complete non-starter to begin with. > > Are there other helpers of concern that come immediately to mind? A first stab might > add these to the list in the verifier that require privilege. This has the drawback that > programs that actually need this kind of functionality are beyond the test framework. So far majority of programs require root-only verifier features. The programs are getting more complex and benefit the most from testing. Relaxing test_run for unpriv progs is imo very narrow use case. I'd rather use CAP_BPF.
