On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@xxxxxxxxx> wrote: > On Wed, 3 Oct 2018, Kees Cook wrote: > >> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@xxxxxxxxx> wrote: >> > On Tue, 2 Oct 2018, John Johansen wrote: >> >> To me a list like >> >> lsm.enable=X,Y,Z >> > >> > What about even simpler: >> > >> > lsm=selinux,!apparmor,yama >> >> We're going to have lsm.order=, so I'd like to keep it with a dot >> separator (this makes it more like module parameters, too). You want >> to mix enable/disable in the same string? That implies you'd want >> implicit enabling (i.e. it complements the builtin enabling), which is >> opposite from what John wanted. >> > > Why can't this be the order as well? That was covered extensively in the earlier threads. It boils down to making sure we do not create a pattern of leaving LSMs disabled by default when they are added to the kernel. The v1 series used security= like this: + security= [SECURITY] An ordered comma-separated list of + security modules to attempt to enable at boot. If + this boot parameter is not specified, only the + security modules asking for initialization will be + enabled (see CONFIG_DEFAULT_SECURITY). Duplicate + or invalid security modules will be ignored. The + capability module is always loaded first, without + regard to this parameter. This meant booting "security=apparmor" would disable all the other LSMs, which wasn't friendly at all. So "security=" was left alone (to leave it to only select the "major" LSM: all major LSMs not matching "security=" would be disabled). So I proposed "lsm.order=" to specify the order things were going to be initialized in, but to avoid kernels booting with newly added LSMs forced-off due to not being listed in "lsm.order=", it had to have implicit fall-back for unlisted LSMs. (i.e. anything missing from lsm.order would then follow their order in CONFIG_LSM_ORDER, and anything missing there would fall back to link-time ordering.) However, then the objection was raised that this didn't provide a way to explicitly disable an LSM. So I proposed lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over CONFIG_LSM_DISABLE. -Kees -- Kees Cook Pixel Security
