bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Edwin Peer <epeer@juniper.net>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Y Song <ys114321@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"ast@kernel.org" <ast@kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [RFC PATCH bpf-next 0/2] unprivileged BPF_PROG_TEST_RUN
Date: Thu, 19 Dec 2019 17:05:42 +0000	[thread overview]
Message-ID: <CEA84064-FF2B-4AA7-84EE-B768D6ABC077@juniper.net> (raw)
In-Reply-To: <20191219154704.GC4198@linux-9.fritz.box>

On 12/19/19, 07:47, "Daniel Borkmann" <daniel@iogearbox.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
  


  reply	other threads:[~2019-12-19 17:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20191219013534.125342-1-epeer@juniper.net>
2019-12-19  7:19 ` [RFC PATCH bpf-next 0/2] unprivileged BPF_PROG_TEST_RUN Y Song
2019-12-19 14:50   ` Edwin Peer
2019-12-19 15:47     ` Daniel Borkmann
2019-12-19 17:05       ` Edwin Peer [this message]
2019-12-19 19:26         ` Alexei Starovoitov
2019-12-19 20:06           ` Edwin Peer
2019-12-19 21:52             ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CEA84064-FF2B-4AA7-84EE-B768D6ABC077@juniper.net \
    --to=epeer@juniper.net \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    --cc=ys114321@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).