Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp514600ybi; Sat, 29 Jun 2019 16:48:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqyJxj9Pb4bwmxgJc6qvBiZ0pSLRNyhrCmjox70tmSvH6CFGuRzHC2ep70bQJtZG5C/DaR4C X-Received: by 2002:a17:90a:8a15:: with SMTP id w21mr22115820pjn.134.1561852128293; Sat, 29 Jun 2019 16:48:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561852128; cv=none; d=google.com; s=arc-20160816; b=r3QsJCA+qmqNxAltMi+9lPb1CU+m1/xLs3lGzgooKbLiid3OvVERYd4zoyy+jXzguT oIVua9Wd5iEkW0Nn/AKMj0sGwAnBnRNJCfuyEZYf9HgImCqq8QT95hHAEM9laH3mo5Jz X3YjBPGNGqtXDdRMag18J28AqmLNjyi/zF3EqOQ5ivoZy20WhlZgQ5DGp10T4S7CofCM 5ZSrb/WZol9nBrW9eUce+z9w6MeJVLhSWJ4NBLXFsAl0sGI0loOdjJIIBhZJKgKMKtCV h2tNLNMPs8p++haczsrXsvMoh7FDpzKfkSP67eTbJnXTgmkNkXpPWxMVefyFEF6wWvbq kEZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=gu0y/u0Wt2OfctZ9vD4Qkvhts0r/c1ZmSVK9pJx8HvQ=; b=R48L2KmlrRw8Ge3zN1KTu1Wz1LUEL7jrcH5bOach0XKgXHDYUngJLdPc7coQX/sJZo yEZlV8IdSMNoz0excLYYixrl7Wh6mDkvJZE+91IQoAtXxnDFpu+gj8F4u07tngwOH+Iq gnk9u0f/nmi3Q3yYhVKcmnGN9Sr5AHX+7iScmdSpmOmf9cIQ+RgPoLO9cAbQ74a0ifP0 0DlsO3SqI5OHaMKyuaOnhBIIyAYdChKaILTsvJ44YkgaldF2MvH2uw3M2iJ22KM60prY hS8CFW0i+kKnh0ftEHyCo4jyAPmrEjfA3u4dLrUqIn+FhKdTUw6muaik03fd4NjMZj9z +igQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=DhmTf41Y; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m129si6493461pfm.118.2019.06.29.16.48.32; Sat, 29 Jun 2019 16:48:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=DhmTf41Y; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726990AbfF2XsH (ORCPT + 99 others); Sat, 29 Jun 2019 19:48:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:58330 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726952AbfF2XsG (ORCPT ); Sat, 29 Jun 2019 19:48:06 -0400 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 1796D217D6 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-f49.google.com with SMTP id a15so12379059wmj.5 for ; Sat, 29 Jun 2019 16:48:05 -0700 (PDT) X-Gm-Message-State: APjAAAWp34M5iINPBBRjK6WqDuy/ryoZQjk6omb9a6OVergDZlVL5Y6B hHjWBBRxjcfbn0mlzSjXF5hvYIrmoudwRoEzb45Ytw== 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: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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.