From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexei Starovoitov Subject: Re: [PATCH bpf-next] bpf, capabilities: introduce CAP_BPF Date: Tue, 27 Aug 2019 21:49:05 -0700 Message-ID: <20190828044903.nv3hvinkkolnnxtv@ast-mbp.dhcp.thefacebook.com> References: <20190827205213.456318-1-ast@kernel.org> <20190828003447.htgzsxs5oevn3eys@ast-mbp.dhcp.thefacebook.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org To: Andy Lutomirski Cc: Alexei Starovoitov , Kees Cook , LSM List , James Morris , Jann Horn , Peter Zijlstra , Masami Hiramatsu , Steven Rostedt , "David S. Miller" , Daniel Borkmann , Network Development , bpf , kernel-team , Linux API List-Id: linux-api@vger.kernel.org On Tue, Aug 27, 2019 at 07:00:40PM -0700, Andy Lutomirski wrote: > > Let me put this a bit differently. Part of the point is that > CAP_TRACING should allow a user or program to trace without being able > to corrupt the system. CAP_BPF as you’ve proposed it *can* likely > crash the system. Really? I'm still waiting for your example where bpf+kprobe crashes the system...