From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Alexei Starovoitov <ast@plumgrid.com>,
"David S. Miller" <davem@davemloft.net>
Cc: Andy Lutomirski <luto@amacapital.net>,
Ingo Molnar <mingo@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Kees Cook <keescook@chromium.org>,
linux-api@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 net-next 1/3] bpf: enable non-root eBPF programs
Date: Thu, 08 Oct 2015 20:20:52 +0200 [thread overview]
Message-ID: <1444328452.3935641.405110585.76554E06@webmail.messagingengine.com> (raw)
In-Reply-To: <1444281803-24274-2-git-send-email-ast@plumgrid.com>
Hi Alexei,
On Thu, Oct 8, 2015, at 07:23, Alexei Starovoitov wrote:
> The feature is controlled by sysctl kernel.unprivileged_bpf_disabled.
> This toggle defaults to off (0), but can be set true (1). Once true,
> bpf programs and maps cannot be accessed from unprivileged process,
> and the toggle cannot be set back to false.
This approach seems fine to me.
I am wondering if it makes sense to somehow allow ebpf access per
namespace? I currently have no idea how that could work and on which
namespace type to depend or going with a prctl or even cgroup maybe. The
rationale behind this is, that maybe some namespaces like openstack
router namespaces could make usage of advanced ebpf capabilities in the
kernel, while other namespaces, especially where untrusted third parties
are hosted, shouldn't have access to those facilities.
In that way, hosters would be able to e.g. deploy more efficient
performance monitoring container (which should still need not to run as
root) while the majority of the users has no access to that. Or think
about routing instances in some namespaces, etc. etc.
Thanks,
Hannes
next prev parent reply other threads:[~2015-10-08 18:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-08 5:23 [PATCH v2 net-next 0/3] bpf: unprivileged Alexei Starovoitov
2015-10-08 5:23 ` [PATCH v2 net-next 1/3] bpf: enable non-root eBPF programs Alexei Starovoitov
2015-10-08 17:45 ` Kees Cook
2015-10-08 18:20 ` Hannes Frederic Sowa [this message]
2015-10-08 22:05 ` Alexei Starovoitov
2015-10-09 11:45 ` Hannes Frederic Sowa
2015-10-09 17:30 ` Alexei Starovoitov
2015-10-09 17:45 ` Daniel Borkmann
2015-10-09 17:59 ` Alexei Starovoitov
2015-10-09 9:28 ` Thomas Graf
2015-10-08 5:23 ` [PATCH v2 net-next 2/3] bpf: charge user for creation of BPF maps and programs Alexei Starovoitov
2015-10-08 5:23 ` [PATCH v2 net-next 3/3] bpf: add unprivileged bpf tests Alexei Starovoitov
2015-10-08 17:46 ` Kees Cook
2015-10-08 17:55 ` Alexei Starovoitov
2015-10-13 2:22 ` [PATCH v2 net-next 0/3] bpf: unprivileged David Miller
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=1444328452.3935641.405110585.76554E06@webmail.messagingengine.com \
--to=hannes@stressinduktion.org \
--cc=ast@plumgrid.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
/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
all inboxes | Powered by JetHome®