From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A55FC3A59B for ; Mon, 19 Aug 2019 09:15:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1244E2184D for ; Mon, 19 Aug 2019 09:15:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727300AbfHSJPa (ORCPT ); Mon, 19 Aug 2019 05:15:30 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:46607 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726661AbfHSJPa (ORCPT ); Mon, 19 Aug 2019 05:15:30 -0400 Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hzdku-00009b-Bv; Mon, 19 Aug 2019 11:15:12 +0200 Date: Mon, 19 Aug 2019 11:15:11 +0200 (CEST) From: Thomas Gleixner To: Alexei Starovoitov cc: Jordan Glover , Andy Lutomirski , Daniel Colascione , Song Liu , Kees Cook , Networking , bpf , Alexei Starovoitov , Daniel Borkmann , Kernel Team , Lorenz Bauer , Jann Horn , Greg KH , Linux API , LSM List Subject: Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf In-Reply-To: <20190817150245.xxzxqjpvgqsxmloe@ast-mbp> Message-ID: References: <20190814220545.co5pucyo5jk3weiv@ast-mbp.dhcp.thefacebook.com> <20190815172856.yoqvgu2yfrgbkowu@ast-mbp.dhcp.thefacebook.com> <20190815230808.2o2qe7a72cwdce2m@ast-mbp.dhcp.thefacebook.com> <20190816195233.vzqqbqrivnooohq6@ast-mbp.dhcp.thefacebook.com> <20190817150245.xxzxqjpvgqsxmloe@ast-mbp> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Alexei, On Sat, 17 Aug 2019, Alexei Starovoitov wrote: > On Fri, Aug 16, 2019 at 10:28:29PM +0200, Thomas Gleixner wrote: > > On Fri, 16 Aug 2019, Alexei Starovoitov wrote: > > While real usecases are helpful to understand a design decision, the design > > needs to be usecase independent. > > > > The kernel provides mechanisms, not policies. My impression of this whole > > discussion is that it is policy driven. That's the wrong approach. > > not sure what you mean by 'policy driven'. > Proposed CAP_BPF is a policy? I was referring to the discussion as a whole. > Can kernel.unprivileged_bpf_disabled=1 be used now? > Yes, but it will weaken overall system security because things that > use unpriv to load bpf and CAP_NET_ADMIN to attach bpf would need > to move to stronger CAP_SYS_ADMIN. > > With CAP_BPF both load and attach would happen under CAP_BPF > instead of CAP_SYS_ADMIN. I'm not arguing against that. > > So let's look at the mechanisms which we have at hand: > > > > 1) Capabilities > > > > 2) SUID and dropping priviledges > > > > 3) Seccomp and LSM > > > > Now the real interesting questions are: > > > > A) What kind of restrictions does BPF allow? Is it a binary on/off or is > > there a more finegrained control of BPF functionality? > > > > TBH, I can't tell. > > > > B) Depending on the answer to #A what is the control possibility for > > #1/#2/#3 ? > > Can any of the mechanisms 1/2/3 address the concern in mds.rst? Well, that depends. As with any other security policy which is implemented via these mechanisms, the policy can be strict enough to prevent it by not allowing certain operations. The more fine-grained the control is, it allows the administrator who implements the policy to remove the 'dangerous' parts from an untrusted user. So really question #A is important for this. Is BPF just providing a binary ON/OFF knob or does it allow to disable/enable certain aspects of BPF functionality in a more fine grained way? If the latter, then it might be possible to control functionality which might be abused for exploits of some sorts (including MDS) in a way which allows other parts of BBF to be exposed to less priviledged contexts. > I believe Andy wants to expand the attack surface when > kernel.unprivileged_bpf_disabled=0 > Before that happens I'd like the community to work on addressing the text above. Well, that text above can be removed when the BPF wizards are entirely sure that BPF cannot be abused to exploit stuff. Thanks, tglx