[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CEA84064-FF2B-4AA7-84EE-B768D6ABC077@juniper.net>
Date: Thu, 19 Dec 2019 17:05:42 +0000
From: Edwin Peer <epeer@...iper.net>
To: Daniel Borkmann <daniel@...earbox.net>
CC: 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, 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.
> 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.
Another idea might be to have some kind of test classification stored in the program
context. That way, dangerous helpers could be replaced by versions that mock the
functionality in some safe way. Perhaps having test programs only have access to a
subset of virtual netdevs for clone redirect, for example.
Regards,
Edwin Peer
Powered by blists - more mailing lists