On Wed, 3 Oct 2018, Kees Cook wrote:

On Wed, Oct 3, 2018 at 11:28 AM, James Morris [off-list ref] wrote:

quoted

On Wed, 3 Oct 2018, Kees Cook wrote:

quoted

On Wed, Oct 3, 2018 at 11:17 AM, James Morris [off-list ref] wrote:

quoted

On Tue, 2 Oct 2018, John Johansen wrote:

quoted

To me a list like
  lsm.enable=X,Y,Z

What about even simpler:

lsm=selinux,!apparmor,yama

We're going to have lsm.order=, so I'd like to keep it with a dot
separator (this makes it more like module parameters, too). You want
to mix enable/disable in the same string? That implies you'd want
implicit enabling (i.e. it complements the builtin enabling), which is
opposite from what John wanted.

Why can't this be the order as well?

That was covered extensively in the earlier threads. It boils down to
making sure we do not create a pattern of leaving LSMs disabled by
default when they are added to the kernel. The v1 series used
security= like this:

+       security=       [SECURITY] An ordered comma-separated list of
+                       security modules to attempt to enable at boot. If
+                       this boot parameter is not specified, only the
+                       security modules asking for initialization will be
+                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
+                       or invalid security modules will be ignored. The
+                       capability module is always loaded first, without
+                       regard to this parameter.

This meant booting "security=apparmor" would disable all the other
LSMs, which wasn't friendly at all. So "security=" was left alone (to
leave it to only select the "major" LSM: all major LSMs not matching
"security=" would be disabled). So I proposed "lsm.order=" to specify
the order things were going to be initialized in, but to avoid kernels
booting with newly added LSMs forced-off due to not being listed in
"lsm.order=", it had to have implicit fall-back for unlisted LSMs.
(i.e. anything missing from lsm.order would then follow their order in
CONFIG_LSM_ORDER, and anything missing there would fall back to
link-time ordering.) However, then the objection was raised that this
didn't provide a way to explicitly disable an LSM. So I proposed
lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
CONFIG_LSM_DISABLE.

Ok, but it may end up being clearer, simpler, and thus more secure to just 
have a single way to configure LSM.

For example:

  - All LSMs which are built are NOT enabled by default

  - You specify enablement and order via a Kconfig:

	CONFIG_LSM="selinux,yama"

  - This can be entirely overridden by a boot param:

	lsm="apparmor,landlock"

And that's it.

Of course, capabilities is always enabled and not be visible to kconfig or 
boot params.


-- 
James Morris
[off-list ref]