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 69052C282DD for ; Thu, 9 Jan 2020 18:12:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3E199206ED for ; Thu, 9 Jan 2020 18:12:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732084AbgAISMx (ORCPT ); Thu, 9 Jan 2020 13:12:53 -0500 Received: from namei.org ([65.99.196.166]:56486 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730353AbgAISMx (ORCPT ); Thu, 9 Jan 2020 13:12:53 -0500 Received: from localhost (localhost [127.0.0.1]) by namei.org (8.14.4/8.14.4) with ESMTP id 009IBcbB024844; Thu, 9 Jan 2020 18:11:38 GMT Date: Fri, 10 Jan 2020 05:11:38 +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: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org 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. This would be similar to the difference between iptables rules and loadable eBPF networking code. I'd be interested to know how the eBPF networking scenarios are handled wrt kernel ABI. > Again, not arguing for or against, but wondering if people fully understand > the implications. If it ends up being useful, people will build access > control systems with it, and it directly exposes a lot of kernel internals to > userspace. There was a lot of concern originally about the LSM hook interface > becoming a stable ABI and/or about it being misused. Exposing that interface > along with every kernel data structure exposed through it to userspace seems > like a major leap. Agreed this is a leap, although I'm not sure I'd characterize it as exposure to userspace -- it allows dynamic extension of the LSM API from userland, but the code is executed in the kernel. KP: One thing I'd like to understand better is the attack surface introduced by this. IIUC, the BTF fields are read only, so the eBPF code should not be able to modify any LSM parameters, correct? > Even if the mainline kernel doesn't worry about any kind > of stable interface guarantees for it, the distros might be forced to provide > some kABI guarantees for it to appease ISVs and users... How is this handled currently for other eBPF use-cases? -- James Morris