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

[Kees Cook]

On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
> On 10/02/2018 07:54 PM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
>> <john.johansen@xxxxxxxxxxxxx> wrote:
>>>
>>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>>>
>>>> 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.
>>
>>
>> That's not how I have it currently. It's a comma-separated a string,
>> including the reserved name "all". The default would just be
>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
>> capture new LSMs by default at build-time.
>>
>>>> - Boot time enabling for selinux= and apparmor= remain
>>>> - lsm.enable= is explicit: overrides above and omissions are disabled
>>>
>>> wfm
>>
>>
>> Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
>> about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
>> would be replacing its functionality.)
>
>
> I'd like to know how distro kernel maintainers feel about it. They would
> need to understand that if they were previously setting
> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE to 0 and want to preserve that
> behavior, then they must set CONFIG_LSM_ENABLE explicitly to a list of
> security modules (that does not include selinux, of course).  In practice,

That's not how it would be done. See below...

> this means that even the distros that choose to build all security modules
> into their kernels must explicitly set CONFIG_LSM_ENABLE to a specific list
> of security modules.  So no one would use "all" in practice.

This is why I had originally wanted to do CONFIG_LSM_DISABLE. Right
now, distro kernel maintainers have two ways to trigger enablement:
via the SELinux and AppArmor BOOTPARAM_VALUE _and_ DEFAULT_SECURITY
(which is an implicit "enable" for Smack or TOMOYO). All the minors
are on-if-built. So, really, the BOOTPARAM_VALUEs were only used for
disabling. Distros would build what they wanted, then use
DEFAULT_SECURITY for their desired major, and if their
DEFAULT_SECURITY wasn't SELinux or AppArmor, they'd _also_ have to set
those BOOTPARAM_VALUEs to 0.

The goal of the series is to split this more cleanly between "enable"
and "order": the way to handle the LSMs is to enable _everything_ and
then set the desired init order: the first exclusive "wins". So I *do*
think the default would be CONFIG_LSM_ENALBE=all, since it's
CONFIG_LSM_ORDER= that effectively replaces CONFIG_DEFAULT_SECURITY.

Either a distro builds a very specific subset of LSMs, or they build
in all LSMs (for the user to choose from). In both cases, they set an
explicit order, which defines which exclusive LSM get selected.

AppArmor wants to drop BOOTPARAM_VALUE, which make sense, since it's
even now redundant to CONFIG_DEFAULT_SECURITY. I think it makes sense
to drop SELinux's BOOTPARAM_VALUE too. The current way to "enable" a
major LSM is via CONFIG_DEFAULT_SECURITY. No sane distro kernel is
going to set CONFIG_DEFAULT_SECURITY=selinux and
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0. If you wanted no major LSM
(but still build them all in), you'd set CONFIG_DEFAULT_SECURITY="".

-Kees

-- 
Kees Cook
Pixel Security