On 10/02/2018 03:06 PM, James Morris wrote:

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

why add the lsm. prefix? I think if we go this route
selinux.enable=x
apparmor.enable=x

is a little cleaner

the question then becomes is this easier for users? Doing something
similar to this was discussed earlier but its more tedious to type
each of these out, and since they are separate options they can
get spread out making it easy to miss one when you are changing
your boot options.

I honestly don't think we are going to come to a consensus on what is
best for users because different sets of users have different priorities.
But I do think we need to come up with something cleaner than v3

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

this will break the user api, not just the distro/builder kernel
config. I do think it is probably worth doing, but not everyone agrees.

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.

yes docs can be updated but it does take time to propagate out and their
are always the dozens of blog, and forum posts etc that google will
drag up that won't get updated

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

yes, but users who have been taught to add certain incantations to their
kernel parameters find it a lot harder

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

I'm not opposed to taking a one-time hit for usability in the future.