Netdev Archive on
 help / color / Atom feed
From: Matthew Garrett <>
To: Andy Lutomirski <>
Cc: Stephen Smalley <>,
	James Morris <>,,
	LKML <>,
	Linux API <>,
	David Howells <>,
	Alexei Starovoitov <>,
	Network Development <>,
	Chun-Yi Lee <>,
	Daniel Borkmann <>,
	LSM List <>
Subject: Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
Date: Fri, 28 Jun 2019 11:47:12 -0700
Message-ID: <> (raw)
In-Reply-To: <>

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?

  reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2019-06-21  1:19 ` Matthew Garrett
2019-06-21  5:22   ` Andy Lutomirski
2019-06-21 20:05     ` Matthew Garrett
2019-06-26 20:22     ` James Morris
2019-06-27  0:57       ` Andy Lutomirski
2019-06-27 14:35         ` Stephen Smalley
2019-06-27 18:06           ` James Morris
2019-06-27 20:16             ` Stephen Smalley
2019-06-27 23:16               ` Matthew Garrett
2019-06-27 23:23                 ` Andy Lutomirski
2019-06-27 23:27           ` Andy Lutomirski
2019-06-28 18:47             ` Matthew Garrett [this message]
2019-06-29 23:47               ` Andy Lutomirski

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Netdev Archive on

Archives are clonable:
	git clone --mirror netdev/git/0.git
	git clone --mirror netdev/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 netdev netdev/ \
	public-inbox-index netdev

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox