On Thu, Dec 19, 2019 at 08:06:21PM +0000, Edwin Peer wrote: > On 12/19/19, 11:26, "Alexei Starovoitov" <alexei.starovoitov@xxxxxxxxx> wrote: > > > 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. > > I'm trying to provide access to BPF testing infrastructure for unprivileged > users (assuming it can be done in a safe way, which I'm as yet unsure of). > CAP_BPF is not the same thing, because at least some kind of root > intervention is required to attain CAP_BPF in the first place. yes and test infra can bet setup with CAP_BPF. The desire of testing frameworks to work without root was one of the main motivations for us to work on CAP_BPF. > > Whether bpf_clone_redirect() is such helper is still tbd. Unpriv user can flood netdevs > > without any bpf. > > True, but presumably such would still be subject to administrator > controlled QoS and firewall policy? Also unprivileged users presumably > can't create arbitrary packets coming from spoofed IPs / MACs, which I > believe requires CAP_NET_RAW? > > >> 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. > > The more elaborate proposal called for mocking these aspects for > testing, which could conceivably resolve this? That said, I see an > incremental path to this, adding such as needed. The narrowness > of the use case really depends on exactly what you're trying to do. > Something in XDP, for example, has very little kernel dependencies > (possibly none that would be affected here) and represents an entire > class of use cases that could have unprivileged testing be supported. I'm looking at public and non-public XDP progs and none of them are verifiable as unpriv. I don't think it's a good idea to build infra for toy programs.
