On 10/03/2018 10:26 AM, Kees Cook wrote: > 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. > but distinct of first exclusive (major) will likely be going away once full lsm stacking land. > 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. > and when lsm stacking lands, that exlusive LSM goes away. > 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="". >
