From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754601AbbJGVUr (ORCPT ); Wed, 7 Oct 2015 17:20:47 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:35614 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754681AbbJGVUp (ORCPT ); Wed, 7 Oct 2015 17:20:45 -0400 Subject: Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs To: Daniel Borkmann , "David S. Miller" 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> 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 From: Alexei Starovoitov Message-ID: <56158CAF.9030209@plumgrid.com> Date: Wed, 7 Oct 2015 14:20:47 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5613C261.4080302@iogearbox.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. 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. Thoughts?