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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 09799C5B57B for ; Sat, 29 Jun 2019 23:48:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D3FD121726 for ; Sat, 29 Jun 2019 23:48:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561852090; bh=/Z9JxHM/U8pOR2q9Q111pLKFbaSLjxZI1rBO4UNXjGs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=NC7iciWedy51tVwTz00ZvA/VfcrpshA6oZ8XYZI4bIlohFx0vECF/DGXA3YVFRXJT qYhEAxzJXKo/Hn+eKkBzNMc++24Iu5eQqhBGLdmpbCW00Cz1qVIkcZVKF9+iPh/J7b nrx4MO7nAdOU4SuWdLG/yhyPbMjCR/6h+WxBIMp4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726977AbfF2XsH (ORCPT ); Sat, 29 Jun 2019 19:48:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:58334 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726956AbfF2XsG (ORCPT ); Sat, 29 Jun 2019 19:48:06 -0400 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1688D21773 for ; Sat, 29 Jun 2019 23:48:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561852085; bh=/Z9JxHM/U8pOR2q9Q111pLKFbaSLjxZI1rBO4UNXjGs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DhmTf41Y2AuaabsMozTRzHIZvaRyAuQnNAVsjlAdX17h5VfZCAAt73CqYND0OuWLT Lq4O6ZKNaaR2s6Xde+Jhb4vpZSxaF7h0FlO1NZ6Zu41SuIQF4k0VerykHuEEWED+Xa 1d9VWfWJonrnFa53poGTxTuBHSXOqSfoVPIl25NE= Received: by mail-wm1-f48.google.com with SMTP id x15so12387089wmj.3 for ; Sat, 29 Jun 2019 16:48:05 -0700 (PDT) X-Gm-Message-State: APjAAAUx8TyFBFoHmrmLeO59/U30ivDy11GLtoHpDdMSLxj0/Ul16sLN L2QLROomyol3I0cVtXadu9FoutSprHJAEaX2B8kuHw== X-Google-Smtp-Source: APXvYqwPvmJHkMRl329cQ9T4D/2dboMc6Y5O8FWBmYdZc9xtZrbDnQPOXbb072fAhtMQs+QCOGRqxnm2IlTbXokTVhU= X-Received: by 2002:a1c:1a56:: with SMTP id a83mr12548344wma.161.1561852083701; Sat, 29 Jun 2019 16:48:03 -0700 (PDT) MIME-Version: 1.0 References: <20190621011941.186255-1-matthewgarrett@google.com> <20190621011941.186255-25-matthewgarrett@google.com> <6E53376F-01BB-4795-BC02-24F9CAE00001@amacapital.net> In-Reply-To: From: Andy Lutomirski Date: Sat, 29 Jun 2019 16:47:52 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode To: Matthew Garrett Cc: Andy Lutomirski , Stephen Smalley , James Morris , linux-security@vger.kernel.org, LKML , Linux API , David Howells , Alexei Starovoitov , Network Development , Chun-Yi Lee , Daniel Borkmann , LSM List Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Jun 28, 2019 at 11:47 AM Matthew Garrett wrote: > > On Thu, Jun 27, 2019 at 4:27 PM Andy Lutomirski wrote: > > They're really quite similar in my mind. Certainly some things in the > > "integrity" category give absolutely trivial control over the kernel > > (e.g. modules) while others make it quite challenging (ioperm), but > > the end result is very similar. And quite a few "confidentiality" > > things genuinely do allow all kernel memory to be read. > > > > I agree that finer-grained distinctions could be useful. My concern is > > that it's a tradeoff, and the other end of the tradeoff is an ABI > > stability issue. If someone decides down the road that some feature > > that is currently "integrity" can be split into a narrow "integrity" > > feature and a "confidentiality" feature then, if the user policy knows > > about the individual features, there's a risk of breaking people's > > systems. If we keep the fine-grained control, do we have a clear > > compatibility story? > > My preference right now is to retain the fine-grained aspect of things > in the internal API, simply because it'll be more annoying to add it > back later if we want to. I don't want to expose it via the Lockdown > user facing API for the reasons you've described, but it's not > impossible that another LSM would find a way to do this reasonably. > Does it seem reasonable to punt this discussion out to the point where > another LSM tries to do something with this information, based on the > implementation they're attempting? I think I can get behind this, as long as it's clear to LSM authors that this list is only a little bit stable. I can certainly see the use for the fine-grained info being available for auditing.