Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp3617902ybd; Fri, 28 Jun 2019 11:47:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqyRb2qJtZRt032/RSJW5L9jhVugLyVAq0CcShdAuAf5k6RNXws0jpO7nGjFpYKRsnXF3j2g X-Received: by 2002:a17:90a:380d:: with SMTP id w13mr14741042pjb.138.1561747676553; Fri, 28 Jun 2019 11:47:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561747676; cv=none; d=google.com; s=arc-20160816; b=XQerOmSE6wvt31SeeYLIpfpDa8JUl7gYrZJklIdI7ntZUKBhctVtAKkudDDHz9m7o1 kVa/wL2MRhsU+9KEgM4uN0+dbxtRveE4aO8VFoTmFx8k9dA4iFVU7JJqonSYjbDc2rMu yiHPVJKc6RuZ8PruHCY8akPreAmW48cTKMoKDnS3NuaTQ6tUhlmQ3x/UC8bqCmGMSLAJ 3GtRuCNwatweduw+6rFmVYCIIfUgrfRoyMA0m6mEa1LLNkjce9EUV3lN1Qkru+TiXiEY QLK4BuSbZaIN8JJDCTTYiZvqfmyNHVXGaCrmqBnzoJ9JGfdiR52/AbJNk+jXQlz9qC1X R6gQ== 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=TS6M/Nxme28NPi028YG4VL6UkJsnX87eP23dRyQxlL8=; b=sImAKqJCtfLRzjckMC9bwXlV423SP+t2evXtAQ9Nz3Zgtyd5dBNRoLIpHhZgeVYZo/ eH5KCnPb6sv6efKKr0rQof7n6KYKQTzCI/zNL5ezdzaitl8+8mHChjO3zia7FWV1dEeh 2L2vHY/hHt8sJY3JNbtIXVqrJT7J7EVd7elCQTQjJYUm7As4cNZQd8Tq5XD0EfdMVQRu Dd4/WOhtmhuGO1ccxmPEbj+NxkUWSPVt76wWB4HhFlPaDtOf3R2UppcsAb9zf4ahg1P1 4ea6uuVHn1qzPTLh+OPD47y6zWBWHaLl9Tc9mMeFGE+QGNsVq724oxYsQ+CIZs9WtSiK C31Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ULWQJchS; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d12si2925313pla.121.2019.06.28.11.47.41; Fri, 28 Jun 2019 11:47:56 -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=@google.com header.s=20161025 header.b=ULWQJchS; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726887AbfF1Sr0 (ORCPT + 99 others); Fri, 28 Jun 2019 14:47:26 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:34024 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726860AbfF1SrZ (ORCPT ); Fri, 28 Jun 2019 14:47:25 -0400 Received: by mail-io1-f66.google.com with SMTP id k8so14694608iot.1 for ; Fri, 28 Jun 2019 11:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TS6M/Nxme28NPi028YG4VL6UkJsnX87eP23dRyQxlL8=; b=ULWQJchSSBGqlKXWeas4g7WIZ8OlQF02e/2fni6ZOZONXYEs3ZCH+r4cic8fiYxfD0 eHnbXowAwuPBZ89DrfUkpwTDs9b+1pqQrg7eDqxc7WPuE1R1HXMpIVW8H3p/u/Nljjwe nGgIWQLRB86Fr5HVwK/7FifYn8quFD54pQ1rcG7vEyBMJiIh++rAIfHCNZoFUDN6/r6F e0JJ7ljcCosjh6XyxVdTwFEg+Ryd3//WBaWWOHqgiiJ8CleZ6HuUNXCtKg9lh4/OuQKJ R8YskmnppDVe4ergbv2NJAVXObMYFdGbjt93mjBFWt/coimuZTorjdy0ZETQWq8/UYw6 doXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TS6M/Nxme28NPi028YG4VL6UkJsnX87eP23dRyQxlL8=; b=ViMkpBTjlK+GJH1l8Br7xnJxpz2v5wVQrNmMTZt9N0tjbUnWhN++mPeaR0IJf65YqE 9PRYfYC7TUbvEByD3WaoNCnCos8P8US469zqYpkZRwWPoRxZiQBr6dKP8Ws7HggKYX2E Lp2Daeqjgnmi5aUdqlyEUJfzLkHROx7xVLkNhuHQXviTXBCcXQTkXr+VHg53xU6EIV0R xe0DODH7YEqCmB+0ltjto/HSwhxTFdHtaZPrKkl29oDAqdfNxCoAv3soG0HMhnGOkA8X 4OcO7dHNYa9zQw+I8gd9JSkwbfakHT1c0c+oJK0trGPGkY4ug06PaHR5hUTOofLPoHiz DVdg== X-Gm-Message-State: APjAAAX+7xe0o/qm9VqfTpfOCGaF80dywATZ2YHrhJ2O4ebP5+UihE6m 5cu0pU6M/Xo4nJgQhRCxH93gDtUYozaRd3uB27VJMpFGzBw= X-Received: by 2002:a6b:8dcf:: with SMTP id p198mr13241371iod.46.1561747644150; Fri, 28 Jun 2019 11:47:24 -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: Matthew Garrett Date: Fri, 28 Jun 2019 11:47:12 -0700 Message-ID: Subject: Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode To: Andy Lutomirski Cc: 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 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?