From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Borkmann Subject: Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs Date: Thu, 08 Oct 2015 00:07:34 +0200 Message-ID: <561597A6.4000203@iogearbox.net> References: <1444078101-29060-1-git-send-email-ast@plumgrid.com> <1444078101-29060-2-git-send-email-ast@plumgrid.com> <5612F639.2050305@iogearbox.net> <56131B1F.80002@plumgrid.com> <5613C261.4080302@iogearbox.net> <56158CAF.9030209@plumgrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56158CAF.9030209-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Alexei Starovoitov , "David S. Miller" Cc: Andy Lutomirski , Ingo Molnar , Hannes Frederic Sowa , Eric Dumazet , Kees Cook , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-api@vger.kernel.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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756556AbbJGWHs (ORCPT ); Wed, 7 Oct 2015 18:07:48 -0400 Received: from www62.your-server.de ([213.133.104.62]:60793 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754418AbbJGWHq (ORCPT ); Wed, 7 Oct 2015 18:07:46 -0400 Message-ID: <561597A6.4000203@iogearbox.net> Date: Thu, 08 Oct 2015 00:07:34 +0200 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alexei Starovoitov , "David S. Miller" CC: Andy Lutomirski , Ingo Molnar , Hannes Frederic Sowa , Eric Dumazet , Kees Cook , linux-api@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs References: <1444078101-29060-1-git-send-email-ast@plumgrid.com> <1444078101-29060-2-git-send-email-ast@plumgrid.com> <5612F639.2050305@iogearbox.net> <56131B1F.80002@plumgrid.com> <5613C261.4080302@iogearbox.net> <56158CAF.9030209@plumgrid.com> In-Reply-To: <56158CAF.9030209@plumgrid.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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