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 824F3C47409 for ; Thu, 9 Jan 2020 19:08:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5E6212067D for ; Thu, 9 Jan 2020 19:08:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732255AbgAITI1 (ORCPT ); Thu, 9 Jan 2020 14:08:27 -0500 Received: from namei.org ([65.99.196.166]:56530 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388715AbgAITI1 (ORCPT ); Thu, 9 Jan 2020 14:08:27 -0500 Received: from localhost (localhost [127.0.0.1]) by namei.org (8.14.4/8.14.4) with ESMTP id 009J7gso000467; Thu, 9 Jan 2020 19:07:42 GMT Date: Fri, 10 Jan 2020 06:07:42 +1100 (AEDT) From: James Morris To: Stephen Smalley cc: Kees Cook , KP Singh , Casey Schaufler , open list , bpf , linux-security-module@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , Thomas Garnier , Michael Halcrow , Paul Turner , Brendan Gregg , Jann Horn , Matthew Garrett , Christian Brauner , =?ISO-8859-15?Q?Micka=EBl_Sala=FCn?= , Florent Revest , Brendan Jackman , Martin KaFai Lau , Song Liu , Yonghong Song , "Serge E. Hallyn" , Mauro Carvalho Chehab , "David S. Miller" , Greg Kroah-Hartman , Nicolas Ferre , Stanislav Fomichev , Quentin Monnet , Andrey Ignatov , Joe Stringer , Paul Moore Subject: Re: [PATCH bpf-next v1 00/13] MAC and Audit policy using eBPF (KRSI) In-Reply-To: Message-ID: References: <20191220154208.15895-1-kpsingh@chromium.org> <95036040-6b1c-116c-bd6b-684f00174b4f@schaufler-ca.com> <201912301112.A1A63A4@keescook> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Thu, 9 Jan 2020, Stephen Smalley wrote: > On 1/9/20 1:11 PM, James Morris wrote: > > On Wed, 8 Jan 2020, Stephen Smalley wrote: > > > > > The cover letter subject line and the Kconfig help text refer to it as a > > > BPF-based "MAC and Audit policy". It has an enforce config option that > > > enables the bpf programs to deny access, providing access control. IIRC, > > > in > > > the earlier discussion threads, the BPF maintainers suggested that Smack > > > and > > > other LSMs could be entirely re-implemented via it in the future, and that > > > such an implementation would be more optimal. > > > > In this case, the eBPF code is similar to a kernel module, rather than a > > loadable policy file. It's a loadable mechanism, rather than a policy, in > > my view. > > I thought you frowned on dynamically loadable LSMs for both security and > correctness reasons? Evaluating the security impact of this is the next step. My understanding is that eBPF via BTF is constrained to read only access to hook parameters, and that its behavior would be entirely restrictive. I'd like to understand the security impact more fully, though. Can the eBPF code make arbitrary writes to the kernel, or read anything other than the correctly bounded LSM hook parameters? > And a traditional security module would necessarily fall > under GPL; is the eBPF code required to be likewise? If not, KRSI is a > gateway for proprietary LSMs... Right, we do not want this to be a GPL bypass. If these issues can be resolved, this may be a "safe" way to support loadable LSM applications. Again, I'd be interested in knowing how this is is handled in the networking stack (keeping in mind that LSM is a much more invasive API, and may not be directly comparable). -- James Morris