From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752556AbdBCVID (ORCPT ); Fri, 3 Feb 2017 16:08:03 -0500 Received: from mail-vk0-f44.google.com ([209.85.213.44]:35990 "EHLO mail-vk0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752437AbdBCVIB (ORCPT ); Fri, 3 Feb 2017 16:08:01 -0500 MIME-Version: 1.0 In-Reply-To: References: <20170118224120.GG9171@mtj.duckdns.org> <20170119005925.GA18554@mtj.duckdns.org> <20170120023907.GA3294@ast-mbp.thefacebook.com> <20170123043154.GA93519@ast-mbp.thefacebook.com> From: Andy Lutomirski Date: Fri, 3 Feb 2017 13:07:39 -0800 Message-ID: Subject: Re: Potential issues (security and otherwise) with the current cgroup-bpf API To: Alexei Starovoitov Cc: Tejun Heo , Michal Hocko , Peter Zijlstra , David Ahern , Andy Lutomirski , Daniel Mack , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , Kees Cook , Jann Horn , "David S. Miller" , Thomas Graf , Michael Kerrisk , Linux API , "linux-kernel@vger.kernel.org" , Network Development Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 23, 2017 at 12:20 PM, Andy Lutomirski wrote: > On Sun, Jan 22, 2017 at 8:31 PM, Alexei Starovoitov > wrote: >> On Thu, Jan 19, 2017 at 08:04:59PM -0800, Andy Lutomirski wrote: >>> restricting the types of sockets that can be created, then you do want >>> the filter to work across namespaces, but seccomp can do that too and >>> the current code doesn't handle netns correctly. >> >> are you saying that seccomp supports netns filtering? please show the proof. > > It can trivially restruct the types of sockets that are created by > filtering on socket(2) syscall parameters, at least on sane > architectures that don't use socketcall(). I think this is actually wrong -- the socket creation filter appears to be called only on inet sockets. Is there a good reason for that? > >> To summarize, I think the 'prog override is not allowed' flag would be >> ok feature to have and I wouldn't mind making it the default when no 'flag' >> field is passed to bpf syscall, but it's not acceptable to remove current >> 'prog override is allowed' behavior. >> So if you insist on changing the default, please implement the flag asap. >> Though from security point of view and ABI point of view there is absolutely >> no difference whether this flag is added today or a year later while >> the default is kept as-is. > > It's too late and I have too little time. I'll try to write a patch > to change the default to just deny attempts to override. Better > behavior can be added later. > > IMO your suggestions about priorities are overcomplicated. For your > instrumentation needs, I can imagine that a simple "make this hook not > run if a descendent has a hook" would do it. For everything else, run > them all in tree order (depending on filter type) and let the eBPF > code do whatever it wants to do. Is there any plan to address this? If not, I'll try to write that patch this weekend.