From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758660AbbJIR72 (ORCPT ); Fri, 9 Oct 2015 13:59:28 -0400 Received: from mail-pa0-f50.google.com ([209.85.220.50]:34631 "EHLO mail-pa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756914AbbJIR7Y (ORCPT ); Fri, 9 Oct 2015 13:59:24 -0400 Subject: Re: [PATCH v2 net-next 1/3] bpf: enable non-root eBPF programs To: Daniel Borkmann , Hannes Frederic Sowa , "David S. Miller" References: <1444281803-24274-1-git-send-email-ast@plumgrid.com> <1444281803-24274-2-git-send-email-ast@plumgrid.com> <1444328452.3935641.405110585.76554E06@webmail.messagingengine.com> <5616E8A8.5020809@plumgrid.com> <87mvvsb6zg.fsf@stressinduktion.org> <5617F9C9.10407@plumgrid.com> <5617FD1C.2030702@iogearbox.net> Cc: Andy Lutomirski , Ingo Molnar , Eric Dumazet , Kees Cook , linux-api@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org From: Alexei Starovoitov Message-ID: <5618007B.70907@plumgrid.com> Date: Fri, 9 Oct 2015 10:59:23 -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: <5617FD1C.2030702@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/9/15 10:45 AM, Daniel Borkmann wrote: > On 10/09/2015 07:30 PM, Alexei Starovoitov wrote: > ... >> Openstack use case is different. There it will be prog_type_sched_cls >> that can mangle packets, change skb metadata, etc under TC framework. >> These are not suitable for all users and this patch leaves >> them root-only. If you're proposing to add CAP_BPF_TC to let containers >> use them without being CAP_SYS_ADMIN, then I agree, it is useful, but >> needs a lot more safety analysis on tc side. > > Well, I think if so, then this would need to be something generic for > tc instead of being specific to a single (out of various) entities > inside the tc framework, but I currently doubt that this makes much > sense. If we allow to operate already at that level, then restricting > to CAP_SYS_ADMIN makes more sense in that specific context/subsys to me. Let me rephrase. I think it would be useful, but I have my doubts that it's manageable, since analyzing dark corners of TC is not trivial. Probably easier to allow prog_type_sched_cls/act under CAP_NET_ADMIN and grant that to trusted apps. Though only tiny bit better than requiring CAP_SYS_ADMIN.