On Tue, Jul 21, 2015 at 5:03 PM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > On 7/21/2015 3:41 PM, Kees Cook wrote: >> On Tue, Jul 21, 2015 at 1:56 PM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >>> On 7/21/2015 1:09 PM, Josh Boyer wrote: >>>> On Tue, Jul 21, 2015 at 3:48 PM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >>>>> On 7/21/2015 12:09 PM, Kees Cook wrote: >>>>>> Now that minor LSMs can cleanly stack with major LSMs, remove the unneeded >>>>>> config for Yama to be made to explicitly stack. Just selecting the main >>>>>> Yama CONFIG will allow it to work, regardless of the major LSM. Since >>>>>> distros using Yama are already forcing it to stack, this is effectively >>>>>> a no-op change. >>>>> Today I can compile in all LSMs including Yama and pick the one I want. >>>>> If we made your change it would be impossible to build in Yama and not >>>>> use it. I suggest we hold off until after the security summit discussion >>>> This is true, but it's also true regardless of stacking. If Yama had >>>> a CONFIG_SECURITY_YAMA_ENABLED (or whatever bikeshed color), then you >>>> could enable Yama and not use it, yes? It would also allow people to >>>> default it as disabled, but then enable it at runtime via the >>>> ptrace_scope sysctl. >>> The way Kees proposed it you would *always* get Yama stacked with >>> your other module if you compile Yama in. Thus, If I compile in >>> SELinux and Yama I cannot run SELinux without Yama. Today, I can >> Yama is entirely controllable from sysctl, so you could build it in >> and set the ptrace_scope setting to 0 at boot. It's already being >> built into distro kernels this way (via the STACKING config), so this >> change is effectively no different. >> >>> compile SELinux and Yama in but run only SELinux. My suggestion is >>> to wait until we can specify the modules to use before we remove >>> the kconfig option that provides that facility today. >> I'm happy to wait, but I'm still going to send my other 2 "minor" LSMs >> before LSS. :) Neither of them would be built into a kernel without >> wanting their functionality, so they'll have the stack "always on" >> semantics if their CONFIG is selected. > > Fair enough then. I'll withdraw my objection. One question comes > to mind, and that is how are you planning to order them? I put > Yama ahead of the "major" modules because that was how it had been > stacked previously. Let's assume that the capability module stays > in the first position. Are you planning to put your new modules > before Yama, before the "major" module(s) or at the end? It shouldn't matter, IMO. Though perhaps that's a mistake, and we should make sure all "minor" LSMs go first? As I have it, it'd be in link order, which is likely not "stable", so perhaps I've just talked myself out of "it shouldn't matter". -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
