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 6979BC3A59D for ; Fri, 16 Aug 2019 20:28:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 49DA4206C1 for ; Fri, 16 Aug 2019 20:28:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727630AbfHPU2s (ORCPT ); Fri, 16 Aug 2019 16:28:48 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:43151 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727589AbfHPU2s (ORCPT ); Fri, 16 Aug 2019 16:28:48 -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 1hyipq-00005o-Km; Fri, 16 Aug 2019 22:28:30 +0200 Date: Fri, 16 Aug 2019 22:28:29 +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: <20190816195233.vzqqbqrivnooohq6@ast-mbp.dhcp.thefacebook.com> Message-ID: References: <20190806011134.p5baub5l3t5fkmou@ast-mbp> <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> 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: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: Alexei, On Fri, 16 Aug 2019, Alexei Starovoitov wrote: > It's both of the above when 'systemd' is not taken literally. > To earlier Thomas's point: the use case is not only about systemd. > There are other containers management systems. > These daemons need to drop privileges to make the system safer == less > prone to corruption due to bugs in themselves. Not necessary security > bugs. Let's take a step back. 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. 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 ? Answering those questions gives us a real scope of what can be achieved independent of use cases and wishful thought out policies. Thanks, tglx