archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <>
To: Paul Moore <>
Cc: Casey Schaufler <>,
	linux-security-module <>,
	James Morris <>,
	LKML <>,
	SE Linux <>,
	John Johansen <>,
	Tetsuo Handa <>,
	Stephen Smalley <>,
	"" <>,
	Alexey Dobriyan <>,
	"Schaufler, Casey" <>
Subject: Re: [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock
Date: Thu, 13 Sep 2018 14:01:48 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Sep 13, 2018 at 12:12 PM, Paul Moore <> wrote:
> None of the above deals with the user experience or support burden a
> distro would have by forcing stacking on.  If we make it an option the

Just to make sure we're clear here: this series does not provide
"extreme" stacking: SELinux, AppArmor, and SMACK remain boot-exclusive
no matter what the CONFIGs.

> distros can choose for themselves; picking a kernel build config is
> not something new to distros, and I think Casey's text adequately
> explains CONFIG_SECURITY_STACKING in terms that would be sufficient.

I absolutely want stacking to be configurable, but I want to point out
that there is no operational difference between

- all the new accessor and allocation code is exercised in both cases

- with stacking enabled: selinux, apparmor, and smack have an offset
of 0 into blobs (and only one can be enabled at a time)

- with stacking disabled: selinux, apparmor, and smack have an offset
of 0 into blobs (and only one can be enabled at a time)

The only behavioral difference is TOMOYO:

1- with stacking disabled and TOMOYO as the only major LSM, it will
have a 0 offset into blobs (like above)

2- with stacking enabled and TOMOYO as the only major LSM, it will
have a 0 offset into blobs (like above)

3- with stacking disabled and another major LSM is enabled, TOMOYO
will be disabled (like always)

4- with stacking enabled and another major LSM is enabled, TOMOYO will
have a non-0 offset into blobs and will run after selinux or smack or
run before apparmor (based on link ordering defined by the Makefile).

Note that cases 1, 2, and 3 are identical in behavior to before this
series. Only case 4 is different, which is why I'm saying that instead
of creating a redundant and needlessly complex config, or reinventing
the "enable" wheel, we should simply drop the no-op
CONFIG_SECURITY_STACKING config and provide TOMOYO with an "enable"
parameter (and CONFIG). And it should be _separate_ from the
"security=" line.

This will be the SAME outcome for distros: if they want stacking, they
choose the "enable TOMOYO by default" CONFIG. If they don't want
stacking, they don't.

> I currently have a neutral stance on stacking, making it mandatory
> pushes me more towards a "no".

This is why I'm trying to explain myself: the infrastructure proposed
here is always exercised, no matter the CONFIG. From that sense it is
"mandatory" no matter what the config is. There isn't a reality where
you could "turn off stacking", because it's not stacking until you
actually stack something, and that will be disabled by default as I've
proposed it.

Let me put this another way: if we simply leave off patch 10, we can
take the other 9 patches (modulo feedback), and we only have to decide
how to expose "stacking"; all the infrastructure work for supporting
it is done.

I'm arguing that "security=" is likely insufficient to describe what
we want, and instead we should focus on individual LSM enablement via
parameters ("tomoyo.enabled=1"). If _ordering_ becomes an issue, we
could either use parameter order, or use "security=" again maybe, but
for now, ordering is already defined by the Makefile (and

"Stacking" only exists if you try to enable one of [selinux, apparmor,
or smack] AND tomoyo. CONFIG_SECURITY_STACKING is redundant: if you
want to disable stacking, you just disable tomoyo if you have another
LSM (which we can already enforce in the Kconfig).

If you want something more explicit than per-LSM config, then a simple
"security.lsm_stack=1/0" with a CONFIG for the default would be fine.
I'm trying to argue against what appears to be needless complexity
around CONFIG_SECURITY_STACK as it was proposed, since it doesn't
provide a meaningful operational change, since exclusivity of major
LSMs is already handled.

> As far as the cpp ifdef's, and other conditionals are concerned, I
> remain unconvinced this is any worse than any other significant
> feature that is a build time option.

That's fine. That's just a code style issue. What I'm trying to show
is that by lifting the allocation logic up out of the LSMs, we've
actually simplified the logic. The "stacking" part will only become a
distro-choice once they knowingly enable TOMOYO or build in SARA
and/or Landlock in the future.


Kees Cook
Pixel Security

  parent reply	other threads:[~2018-09-14  2:13 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-11 16:26 [PATCH v2 00/10] LSM: Module stacking in support of S.A.R.A and Landlock Casey Schaufler
2018-09-11 16:41 ` [PATCH 01/10] procfs: add smack subdir to attrs Casey Schaufler
2018-09-12 22:57   ` Kees Cook
2018-09-11 16:41 ` [PATCH 02/10] Smack: Abstract use of cred security blob Casey Schaufler
2018-09-12 23:04   ` Kees Cook
2018-09-11 16:41 ` [PATCH 03/10] SELinux: " Casey Schaufler
2018-09-12 23:10   ` Kees Cook
2018-09-11 16:41 ` [PATCH 04/10] LSM: Infrastructure management of the " Casey Schaufler
2018-09-12 23:53   ` Kees Cook
2018-09-13 19:01     ` Casey Schaufler
2018-09-13 21:12       ` Kees Cook
2018-09-11 16:41 ` [PATCH 05/10] SELinux: Abstract use of file " Casey Schaufler
2018-09-12 23:54   ` Kees Cook
2018-09-11 16:42 ` [PATCH 06/10] LSM: Infrastructure management of the " Casey Schaufler
2018-09-13  0:00   ` Kees Cook
2018-09-11 16:42 ` [PATCH 07/10] SELinux: Abstract use of inode " Casey Schaufler
2018-09-13  0:23   ` Kees Cook
2018-09-11 16:42 ` [PATCH 08/10] Smack: " Casey Schaufler
2018-09-13  0:24   ` Kees Cook
2018-09-11 16:42 ` [PATCH 09/10] LSM: Infrastructure management of the inode security Casey Schaufler
2018-09-13  0:30   ` Kees Cook
2018-09-11 16:42 ` [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock Casey Schaufler
2018-09-13  4:19   ` Kees Cook
2018-09-13 13:16     ` Paul Moore
2018-09-13 15:19       ` Kees Cook
2018-09-13 19:12         ` Paul Moore
2018-09-13 20:58           ` Jordan Glover
2018-09-13 21:50             ` Paul Moore
2018-09-13 22:04               ` Jordan Glover
2018-09-13 23:01               ` Casey Schaufler
2018-09-13 21:01           ` Kees Cook [this message]
2018-09-13 21:38             ` Paul Moore
2018-09-13 21:51               ` Kees Cook
2018-09-13 23:06                 ` Kees Cook
2018-09-13 23:32                   ` John Johansen
2018-09-13 23:51                     ` Kees Cook
2018-09-14  0:03                       ` Casey Schaufler
2018-09-14  0:06                         ` Kees Cook
2018-09-13 23:51                   ` Casey Schaufler
2018-09-13 23:57                     ` Kees Cook
2018-09-14  0:08                       ` Casey Schaufler
2018-09-14  0:19                         ` Kees Cook
2018-09-14 15:57                           ` Casey Schaufler
2018-09-14 20:05                             ` Kees Cook
2018-09-14 20:47                               ` Casey Schaufler
2018-09-14 18:18                         ` James Morris
2018-09-14 18:23                           ` John Johansen
2018-09-14  0:03                     ` Kees Cook
2018-09-14  2:42                 ` Paul Moore
2018-09-11 20:43 ` [PATCH v2 00/10] LSM: Module stacking in support of S.A.R.A and Landlock James Morris
2018-09-12 21:29 ` James Morris
2018-09-16 16:54   ` Salvatore Mesoraca
2018-09-16 17:25     ` Casey Schaufler
2018-09-16 17:45       ` Salvatore Mesoraca
2018-09-18  7:44   ` Mickaël Salaün
2018-09-18 15:23     ` Casey Schaufler

Reply instructions:

You may reply publicly 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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).