On 10/02/2018 03:06 PM, James Morris wrote: > On Tue, 2 Oct 2018, Kees Cook wrote: > >> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen >> <john.johansen@xxxxxxxxxxxxx> wrote: >>> 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.
