From: Daniel Borkmann <daniel-FeC+5ew28dpmcu3hnIyYJQ@public•gmane.org>
To: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public•gmane.org>,
"David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public•gmane.org>
Cc: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public•gmane.org>,
Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public•gmane.org>,
Hannes Frederic Sowa
<hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public•gmane.org>,
Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public•gmane.org>,
Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public•gmane.org>,
linux-api-u79uwXL29TY76Z2rM5mHXA@public•gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public•gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public•gmane.org
Subject: Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs
Date: Thu, 08 Oct 2015 00:07:34 +0200 [thread overview]
Message-ID: <561597A6.4000203@iogearbox.net> (raw)
In-Reply-To: <56158CAF.9030209-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
On 10/07/2015 11:20 PM, Alexei Starovoitov wrote:
> On 10/6/15 5:45 AM, Daniel Borkmann wrote:
>> Should instead something similar be adapted on bpf(2) as well? Or, would
>> that even be more painful for application developers shipping their stuff
>> through distros in the end (where they might then decide to just setup
>> everything BPF-related and then drop privs)?
>
> I think loading as root and then dropping privs won't work in many
> cases, since apps still need to access maps even after dropping privs
> and today it's not possible, since cap_sys_admin is tested for every
> bpf syscall.
Yep, maps-only would then need to be made accessible in some way.
>> I'm also wondering with regards to seccomp, which could adapt to eBPF at
>> some point and be used by unprivileged programs. Perhaps then, a single
>> paranoia alike setting might not suit to all eBPF subsystem users. Any
>> ideas?
>
> There is no such paranoid sysctl for cBPF, so there is no reason to
> add one for eBPF other than fear.
> Adding multiple sysctl knobs for seccomp, socket, tracing is only
> reflection of even higher fear.
> What sysadmins suppose to do with such sysctl when kernel is kinda
> saying 'may be something unsafe here you're on your own' ?
> Also the presence of this sysctl_bpf_enable_unprivileged or any other
> one doesn't help with CVEs. Any bug with security implications will
> be a CVE regardless, so I think the better course of action is to
> avoid introducing this sysctl.
Yes, I agree with you that there would be a CVE regardless. I still
like the option of configurable access, not a big fan of the sysctl
either. Thinking out loudly, what about a Kconfig option? We started
out like this on bpf(2) itself (initially under expert settings, now
afaik not anymore), and depending on usage scenarios, a requirement
could be to have immutable cap_sys_admin-only, for other use-cases a
requirement on the kernel might instead be to have unprivileged users
as well.
> We've discussed adding something like CAP_BPF to control it,
> but then again, do we want this because of fear of bugs or because
> it's actually needed. I think the design of all CAP_* is to give
> unprivileged users permissions to do something beyond normal that
> can potentially be harmful for other users or the whole system.
> In this case it's not the case. One user can load eBPF programs
> and maps up to its MEMLOCK limit and they cannot interfere with
> other users or affect the host, so CAP_BPF is not necessary either.
Thanks,
Daniel
next prev parent reply other threads:[~2015-10-07 22:07 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 20:48 [PATCH net-next 0/2] bpf: unprivileged Alexei Starovoitov
2015-10-05 20:48 ` [PATCH net-next 1/2] bpf: enable non-root eBPF programs Alexei Starovoitov
2015-10-05 22:14 ` Daniel Borkmann
[not found] ` <5612F639.2050305-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2015-10-06 0:51 ` Alexei Starovoitov
[not found] ` <56131B1F.80002-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-10-06 7:13 ` Ingo Molnar
2015-10-06 8:05 ` Daniel Borkmann
2015-10-06 8:20 ` Ingo Molnar
[not found] ` <20151006082048.GA18287-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-06 8:39 ` Daniel Borkmann
[not found] ` <561388D1.30406-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2015-10-06 17:50 ` Alexei Starovoitov
2015-10-06 17:56 ` Eric Dumazet
[not found] ` <1444154160.9555.5.camel-XN9IlZ5yJG9HTL0Zs8A6p/gx64E7kk8eUsxypvmhUTTZJqsBc5GL+g@public.gmane.org>
2015-10-06 18:05 ` Andy Lutomirski
2015-10-07 6:05 ` Ingo Molnar
2015-10-06 19:26 ` Alexei Starovoitov
[not found] ` <561409EC.5050005-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-10-06 18:03 ` Daniel Borkmann
2015-10-06 12:45 ` Daniel Borkmann
2015-10-07 21:20 ` Alexei Starovoitov
[not found] ` <56158CAF.9030209-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-10-07 22:07 ` Daniel Borkmann [this message]
2015-10-07 22:22 ` Kees Cook
2015-10-07 23:49 ` Alexei Starovoitov
[not found] ` <5615AF92.50402-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-10-08 6:21 ` Ingo Molnar
2015-10-08 6:30 ` Alexei Starovoitov
2015-10-08 17:42 ` Kees Cook
[not found] ` <1444078101-29060-2-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-10-05 21:00 ` Kees Cook
2015-10-05 21:12 ` Alexei Starovoitov
[not found] ` <5612E7C4.1010306-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-10-05 21:16 ` Andy Lutomirski
2015-10-05 21:32 ` Alexei Starovoitov
2015-10-05 22:02 ` Kees Cook
2015-10-06 0:28 ` Alexei Starovoitov
2015-10-08 2:29 ` Alexei Starovoitov
2015-10-05 20:48 ` [PATCH net-next 2/2] bpf: charge user for creation of BPF maps and programs 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=561597A6.4000203@iogearbox.net \
--to=daniel-fec+5ew28dpmcu3hniyyjq@public$(echo .)gmane.org \
--cc=ast-uqk4Ao+rVK5Wk0Htik3J/w@public$(echo .)gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public$(echo .)gmane.org \
--cc=edumazet-hpIqsD4AKlfQT0dZR+AlfA@public$(echo .)gmane.org \
--cc=hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public$(echo .)gmane.org \
--cc=keescook-F7+t8E8rja9g9hUCZPvPmw@public$(echo .)gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public$(echo .)gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public$(echo .)gmane.org \
--cc=luto-kltTT9wpgjJwATOyAt5JVQ@public$(echo .)gmane.org \
--cc=mingo-DgEjT+Ai2ygdnm+yROfE0A@public$(echo .)gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public$(echo .)gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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