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 09:53:43 -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 , Network Development , Linux Containers , Alexei Starovoitov , Sargun Dhillon , Alexei Starovoitov To: Kees Cook , Andy Lutomirski , containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Netdev 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/26/2018 11:38 PM, Kees Cook wrote: > On Mon, Feb 26, 2018 at 8:19 PM, Andy Lutomirski wrote: >> 3. Straight-up bugs. Those are exactly as problematic as verifier >> bugs in any other unprivileged eBPF program type, right? I don't see >> why seccomp is special here. > > My concern is more about unintended design mistakes or other feature > creep with side-effects, especially when it comes to privileges and > synchronization. Getting no-new-privs done correctly, for example, > took some careful thought and discussion, and I'm shy from how painful > TSYNC was on the process locking side, and eBPF has had some rather > ugly flaws in the past (and recently: it was nice to be able to say > for Spectre that seccomp filters couldn't be constructed to make > attacks but eBPF could). Adding the complexity needs to be worth the > gain. I'm on board for doing it, I just want to be careful. :) Another option might be to remove c/eBPF from the equation all together. c/eBPF allows flexibility and that almost always comes at the cost of additional security risk. Seccomp is for enhanced security yes? How about a new seccomp mode that passes in something like a bit vector or hashmap for "simple" white/black list checks validated by kernel code, versus user provided interpreted code? Of course this removes a fair number of things you can currently do or would be able to do with eBPF. Of course, restated from a security point of view, this removes a fair number of things an _attacker_ can do. Presumably the performance improvement would also be significant. Is this an idea worth prototyping? -chrish