netdev - Re: [RFC PATCH bpf-next 0/2] unprivileged BPF_PROG_TEST

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9A7BE6FA-92FD-411F-BF8C-80484F1B0FBA@juniper.net>
Date:   Thu, 19 Dec 2019 20:06:21 +0000
From:   Edwin Peer <epeer@...iper.net>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:     Daniel Borkmann <daniel@...earbox.net>,
        Y Song <ys114321@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "ast@...nel.org" <ast@...nel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [RFC PATCH bpf-next 0/2] unprivileged BPF_PROG_TEST_RUN

On 12/19/19, 11:26, "Alexei Starovoitov" <alexei.starovoitov@...il.com> wrote:

> On Thu, Dec 19, 2019 at 05:05:42PM +0000, Edwin Peer wrote:
>> On 12/19/19, 07:47, "Daniel Borkmann" <daniel@...earbox.net> 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.

> 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.

Regards,
Edwin Peer