On 10/03/2018 01:36 PM, Kees Cook wrote: > On Wed, Oct 3, 2018 at 1:10 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> 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. > > I still think we should have all built LSMs enabled by default, with > CONFIG_LSM_DISABLE available to turn stuff off. CONFIG_LSM_ORDER and this as a distro ubuntu does not want. Ubuntu wants to make yes available by building them in, but does NOT want all the LSM enabled by default, not even necessarily all minor LSMs. As a distro we want a supported set as default, and users can opt-in to new LSMs. If a new LSM comes along we don't want it enabled by default, which happens Using the lsm disable approach. > declares their order, "lsm.order=" works as mentioned, and > "lsm.enable/disable=" make changes to what's enabled. > > (This would be most like the v3 series, swapping CONFIG_LSM_ENABLE for > CONFIG_LSM_DISABLE.) > > It gives us centralized ordering and centralized disabling. Distros > wanting specific LSMs are already building them, so _also_ adding them > to CONFIG_LSM_ENABLE seems redundant to me. Distros wanting all the except as a disto we want to build in all LSMs by default but NOT have new LSMs enabled by default. The disable approach either mean we don't offer new LSMs in the supported kernels, OR me distro patch so we have the enabled by default list. > LSMs just want to declare the order of initialization, and maybe add > some to CONFIG_LSM_DISABLE some day, so they use CONFIG_LSM_ORDER. > individual LSMs may want that. > I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY > in, since it's just a way to disable all the other majors. I don't > like this because it will force LSMs to be disabled that don't need to > be once blob-sharing lands. The whole point of this series is to get > us away from fixed ordering and thinking about "major" vs "minor" and > towards "exclusive" or not, where we can continue to slowly chip away > at exclusivity without breaking anything. > sure we definitely want to get away form "major" vs "minor" and in generally even exclusive, except where to LSMs just can't live with each other. But that doesn't mean dropping something like default security. The mistake with the current DEFAULT_SECURITY was that it only applied to major LSMs, not the minor ones.
