Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2639623ybd; Thu, 27 Jun 2019 16:29:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqyNXxvA5vgXbkHOu+Rmc4oC/6NDmGu1RTKXPMT9O6KGzF8mwew0mpNRGYFhZ8+V2pLISvp6 X-Received: by 2002:a63:4006:: with SMTP id n6mr5925188pga.403.1561678173935; Thu, 27 Jun 2019 16:29:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561678173; cv=none; d=google.com; s=arc-20160816; b=mGuI/yIIyCt2ddQi6uVUDenBJIHI7VmaU+z69fIYFoErP1nLND85qYleD2kpOlpIih cWJ5GXSbsDe8sEvlQN5BVWbDwLzmhVGAY1a01vOKn7oQFvq3/c+dOH0GRbYOoNDENGx7 rjGbgnoSfd9QwO/1AXhhrlJZxtBlo1B8y5L40NcdlpFnlmb1sGlhZFVeYUCd0hf8lN33 mJ5bv/Ij1QTRfQxya+EAO8Ew8p737NZ67tpqmkc3gsh4Q0KS5MtcapOGVeETu+VS42SX FvNsp/mkAV73zD+Jts5ofJnnRI5tE1tr7GR4uWIVfuHqim8buMMy1Qfdr80sgUD0QQ9s 1bug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=cbaIrjrtraSqJO7eO+1a3pip30Eg7JulgrGs94SFbEw=; b=vYYm8ky3WKjnmn0PjdlLWw/HJwygENFieeMM1QRPmjv42CYd4xEbTl5Gq83kTALrrZ z+6XS+8k98d7b6aiwSNb8RNte8NawV8tYlWyTBZUe5csvo6XPoVg056Gk81PXQrYVoYm gmc2IcWoNDaXpp0SToI68BD2ae5tHOLPlgoKJEYHnx+A3kGytRvX96ggMh3hA46+PwUB twLAjrtj7WcBWH2cqFNxyuxHjqlaFR93RQwYRQbjyu6OqR0BviCttWIv9bocmQMfBtfB wIBMuOvONa4IYkjbXbyoLptvhV1wbKrNV/H1XnvXPMEsq6+1M+286JtZb9Zcp00qXQDx ZJlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=TKcI4mKI; 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 95si346307ple.51.2019.06.27.16.29.17; Thu, 27 Jun 2019 16:29:33 -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=TKcI4mKI; 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 S1726678AbfF0X1x (ORCPT + 99 others); Thu, 27 Jun 2019 19:27:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:49688 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726647AbfF0X1v (ORCPT ); Thu, 27 Jun 2019 19:27:51 -0400 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 741B821743 for ; Thu, 27 Jun 2019 23:27:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561678069; bh=mwvETRIDqMs7L43FSkQDKbGmizxBXYSx/D3C9rFWcpg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=TKcI4mKIbOmTQAT+gptb7xEcJi4etDhygArFA35kutGNdsj68LZpy/Y2k+t9XZ4RD k2hodjkdeER/jYb592nL5NxQtWUYolm4AK99A/+7CH0+U2eHtJ16X0Qt3gPl9ajXNk 1FZBm1Fck2MmbTz+1IDkXYMN9WKOo3h1LIKY9O6s= Received: by mail-wr1-f42.google.com with SMTP id c2so4291079wrm.8 for ; Thu, 27 Jun 2019 16:27:49 -0700 (PDT) X-Gm-Message-State: APjAAAWoTBxCsfpFt4MHtjiqXz/PZMqvkzcFRSCQJ4zaUqQaqTgjUNEA fhzE1lQT8+T/F0eUlsU0zKrdvm3pH0ARUjCHbG91Qw== X-Received: by 2002:adf:dd0f:: with SMTP id a15mr3198059wrm.265.1561678067927; Thu, 27 Jun 2019 16:27:47 -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: Thu, 27 Jun 2019 16:27:36 -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: Stephen Smalley Cc: James Morris , 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 , LSM List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 7:35 AM Stephen Smalley wrote: > > On 6/26/19 8:57 PM, Andy Lutomirski wrote: > > > > > >> On Jun 26, 2019, at 1:22 PM, James Morris wrote: > >> > >> [Adding the LSM mailing list: missed this patchset initially] > >> > >>> On Thu, 20 Jun 2019, Andy Lutomirski wrote: > >>> > >>> This patch exemplifies why I don't like this approach: > >>> > >>>> @@ -97,6 +97,7 @@ enum lockdown_reason { > >>>> LOCKDOWN_INTEGRITY_MAX, > >>>> LOCKDOWN_KCORE, > >>>> LOCKDOWN_KPROBES, > >>>> + LOCKDOWN_BPF, > >>>> LOCKDOWN_CONFIDENTIALITY_MAX, > >>> > >>>> --- a/security/lockdown/lockdown.c > >>>> +++ b/security/lockdown/lockdown.c > >>>> @@ -33,6 +33,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIA= LITY_MAX+1] =3D { > >>>> [LOCKDOWN_INTEGRITY_MAX] =3D "integrity", > >>>> [LOCKDOWN_KCORE] =3D "/proc/kcore access", > >>>> [LOCKDOWN_KPROBES] =3D "use of kprobes", > >>>> + [LOCKDOWN_BPF] =3D "use of bpf", > >>>> [LOCKDOWN_CONFIDENTIALITY_MAX] =3D "confidentiality", > >>> > >>> The text here says "use of bpf", but what this patch is *really* doin= g > >>> is locking down use of BPF to read kernel memory. If the details > >>> change, then every LSM needs to get updated, and we risk breaking use= r > >>> policies that are based on LSMs that offer excessively fine > >>> granularity. > >> > >> Can you give an example of how the details might change? > >> > >>> I'd be more comfortable if the LSM only got to see "confidentiality" > >>> or "integrity". > >> > >> These are not sufficient for creating a useful policy for the SELinux > >> case. > >> > >> > > > > I may have misunderstood, but I thought that SELinux mainly needed to a= llow certain privileged programs to bypass the policy. Is there a real exa= mple of what SELinux wants to do that can=E2=80=99t be done in the simplifi= ed model? > > > > The think that specifically makes me uneasy about exposing all of these= precise actions to LSMs is that they will get exposed to userspace in a wa= y that forces us to treat them as stable ABIs. > > 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. 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 node= s. > > - 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. > 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?