From mboxrd@z Thu Jan 1 00:00:00 1970 From: chris hyser Subject: Re: [net-next v3 0/2] eBPF seccomp filters Date: Tue, 27 Feb 2018 16:22:45 -0500 Message-ID: References: <20180226072651.GA27045@ircssh-2.c.rugged-nimbus-611.internal> <20180226230418.46nczgkh5csakyu7@ast-mbp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Cc: Will Drewry , Daniel Borkmann , Netdev , Linux Containers , Alexei Starovoitov , Andy Lutomirski , Sargun Dhillon , Alexei Starovoitov To: Kees Cook Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org List-Id: netdev.vger.kernel.org On 02/27/2018 02:19 PM, Kees Cook wrote: > On Tue, Feb 27, 2018 at 8:59 AM, chris hyser wrote: >> I will try to find that discussion. As someone pointed out here though, eBPF > > A good starting point might be this: > https://lwn.net/Articles/441232/ Thanks. A fair amount of reading referenced there :-). In particular I'll be curious to find out what happened to this idea: "Essentially, that would make for three choices for each system call: enabled, disabled, or filtered." Something like that might address some of the security concerns in that a simple go/no go on syscall number need not incur the performance hit nor increased attack surface of running c/eBPF code, but it is there for argument checking, etc if you need it. Basically instead of the kernel making the flexibility/performance/security trade-off in advance, you leave it to user code/policy. Anyway, lest it is not clear :-), I think your instincts on security and eBPF are dead on. At the same time it is powerful and useful. So, how to make it optional? -chrish