On 10/02/2018 04:06 PM, Kees Cook wrote:

On Tue, Oct 2, 2018 at 3:06 PM, James Morris [off-list ref] wrote:

quoted

On Tue, 2 Oct 2018, Kees Cook wrote:

quoted

On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
[off-list ref] wrote:

quoted

Under the current scheme

lsm.enabled=selinux

could actually mean selinux,yama,loadpin,something_else are
enabled. If we extend this behavior to when full stacking lands

lsm.enabled=selinux,yama

might mean selinux,yama,apparmor,loadpin,something_else

and what that list is will vary from kernel to kernel, which I think
is harder for the user than the lsm.enabled list being what is
actually enabled at boot

Ah, I think I missed this in your earlier emails. What you don't like
here is that "lsm.enable=" is additive. You want it to be explicit.

This is a path to madness.

How about enable flags set ONLY per LSM:

lsm.selinux.enable=x
lsm.apparmor.enable=x

With no lsm.enable, and removing selinux=x and apparmor=x.

Yes this will break existing docs, but they can be updated for newer
kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from
kernel X onwards.

Surely distro packages and bootloaders are able to cope with changes to
kernel parameters?

We can either take a one-time hit now, or build new usability debt, which
will confuse people forever.

I'd like to avoid this for a few reasons:

- this requires per-LSM plumbing instead of centralized plumbing
  - each LSM needs to have its own CONFIG flag
  - each LSM needs to have its own bootparam flag
- SELinux has explicited stated they do not want to lose selinux=
- this doesn't meet John's goal of having a "single explicit enable list"

I can compromise on a single explicit list. My main goal is something that
is consistent and easy for the end user, and I would like to avoid
potential points of confusion if possible.

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

is best as a single explicit enable list, and it would be best to avoid
lsm.disable as it just introduces confusion.

I do think per-LSM bootparams looses the advantages of centralization,
and still requires the user to know some Kconfig info but it also gets
rid of the lsm.disable confusion.

With ordering separated out from being enabled there is a certain
cleanness to it. And perhaps most users are looking to enable/disable
a single lsm, instead of specifying exactly what security they want
on their system.

If we were to go this route I would rather drop the lsm. prefix

I think the current proposal (in the other thread) is likely the
sanest approach:

- Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
- Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
- All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE

Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
available to be enabled by default at boot.

- Boot time enabling for selinux= and apparmor= remain
- lsm.enable= is explicit: overrides above and omissions are disabled

wfm

- maybe include lsm.disable= to disable anything