Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2366667ybd; Thu, 27 Jun 2019 11:08:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqySvcWH+KF+SBnXjOztKImUMTejmAZEkaLD9UYAZ+T3qjACmHZRYG8u+dMrsvYT3Xxq1sNO X-Received: by 2002:a17:90a:3086:: with SMTP id h6mr7773771pjb.14.1561658924308; Thu, 27 Jun 2019 11:08:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561658924; cv=none; d=google.com; s=arc-20160816; b=oI9PvEZQDcjCHnmlf+giFLgBB+CGmcAU9PHSB3/g0Uz0aL1Y9d4np18hY9bieAJXJp SOG0clJYUxdAaE+g4hKZFSd2eXsP2FJJET8T2nMaiw4b+4/Ds2W7iQ1nUTG2/N9MRCpb m8GATAvJ3SqtRc3r7Ezdqnkr4gHNHrIyb/2EQpGqRn3XVxyvLd8L+KrdTZSC3YdFSJWW ye42+cJDoy5CMaImOdltT/JedIK7bmvgROmvi5H+bQvQEKmTNESxAuz/c/sTeNo7KXG/ X/0uGI/lmGMt/FV5tIjys7ilRX2XhZFnDLQT4cvLxw+tapoxIc76uSlCpM33FoeBnLnK w3zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=W05mpEn8hoR8edIHIzZ10tyu1BCbyrTJIk4S9UPG010=; b=yaT3Mz7k+V3K21PdCa82x/XCM1+tyPaaxUZn8TgdnkyttCOrK3cFBuGrQ+9aWx+J5I T98H26tuBXxl53Ako4JMe5NNt40sGzZUWoXmZACXi5HN+etSc46iLNW/cC5qHPBIrGSV 6qUngu4oYSC0ESmyKZV45YA0U01P6cb6oYi/gusja0aWmwFxFF6NXNaI/MtHlgyYt1Wd QkgN5PfSQWOu5p5yNWA97sTpCOco3VDVsmPfLbreFYLR0BpNYiDHdPLoJdEbB+sNzbNm HAHjdunzPrRrve+Nfg0ntsKsM+AuRM/kwTWrITjhYHgsHJSony4Z2tvyz0fIdkaJKXr1 VZtg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 2si2973304ple.275.2019.06.27.11.08.27; Thu, 27 Jun 2019 11:08:44 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726675AbfF0SIJ (ORCPT + 99 others); Thu, 27 Jun 2019 14:08:09 -0400 Received: from namei.org ([65.99.196.166]:49158 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726519AbfF0SII (ORCPT ); Thu, 27 Jun 2019 14:08:08 -0400 Received: from localhost (localhost [127.0.0.1]) by namei.org (8.14.4/8.14.4) with ESMTP id x5RI6c5Z018737; Thu, 27 Jun 2019 18:06:38 GMT Date: Fri, 28 Jun 2019 04:06:38 +1000 (AEST) From: James Morris To: Stephen Smalley cc: Andy Lutomirski , Andy Lutomirski , Matthew Garrett , linux-security@vger.kernel.org, LKML , Linux API , David Howells , Alexei Starovoitov , Matthew Garrett , Network Development , Chun-Yi Lee , Daniel Borkmann , linux-security-module@vger.kernel.org Subject: Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode In-Reply-To: Message-ID: References: <20190621011941.186255-1-matthewgarrett@google.com> <20190621011941.186255-25-matthewgarrett@google.com> <6E53376F-01BB-4795-BC02-24F9CAE00001@amacapital.net> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Jun 2019, Stephen Smalley wrote: > There are two scenarios where finer-grained distinctions make sense: > > - Users may need to enable specific functionality that falls under the > umbrella of "confidentiality" or "integrity" lockdown. Finer-grained lockdown > reasons free them from having to make an all-or-nothing choice between lost > functionality or no lockdown at all. Agreed. This will be used for more than just UEFI secure boot on desktops, e.g. embedded systems using verified boot, where finer grained policy will be needed for what are sometimes very specific use-cases (which may be also covered by other mitigations). > This can be supported directly by the > lockdown module without any help from SELinux or other security modules; we > just need the ability to specify these finer-grained lockdown levels via the > boot parameters and securityfs nodes. If the lockdown LSM implements fine grained policy (rather than the simple coarse grained policy), I'd suggest adding a new lockdown level of 'custom' which by default enables all hooks but allows selective disablement via params/sysfs. This would be simpler than telling users to use a different lockdown LSM for this. > - Different processes/programs may need to use different sets of functionality > restricted via lockdown confidentiality or integrity categories. If we have > to allow all-or-none for the set of interfaces/functionality covered by the > generic confidentiality or integrity categories, then we'll end up having to > choose between lost functionality or overprivileged processes, neither of > which is optimal. > > Is it truly the case that everything under the "confidentiality" category > poses the same level of risk to kernel confidentiality, and similarly for > everything under the "integrity" category? If not, then being able to > distinguish them definitely has benefit. Good question. We can't know the answer to this unless we know how an attacker might leverage access. The value here IMHO is more in allowing tradeoffs to be made by system designers vs. disabling lockdown entirely. > I'm still not clear though on how/if this will compose with or be overridden > by other security modules. We would need some means for another security > module to take over lockdown decisions once it has initialized (including > policy load), and to be able to access state that is currently private to the > lockdown module, like the level. Why not utilize stacking (restrictively), similarly to capabilities? -- James Morris