Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter

[John Johansen <john.johansen@canonical.com>]

On 10/02/2018 04:06 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 3:06 PM, James Morris <jmorris@namei.org> wrote:
>> 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.
> 
> 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