netdev - Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <561597A6.4000203@iogearbox.net>
Date:	Thu, 08 Oct 2015 00:07:34 +0200
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Alexei Starovoitov <ast@...mgrid.com>,
	"David S. Miller" <davem@...emloft.net>
CC:	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...nel.org>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Kees Cook <keescook@...omium.org>, linux-api@...r.kernel.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html