Messages in this thread |  | | Date | Wed, 3 Oct 2018 08:06:12 +1000 (AEST) | From | James Morris <> | Subject | Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter |
| |
On Tue, 2 Oct 2018, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen > <john.johansen@canonical.com> 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
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.
-- James Morris <jmorris@namei.org>
|  |