On 3/27/19 3:23 PM, Casey Schaufler wrote: > On 3/27/2019 3:05 PM, Tetsuo Handa wrote: >> On 2019/03/28 6:43, Kees Cook wrote: >>>>> I don't see problems for an exclusive LSM user (AA, SELinux, Smack) >>>>> also initializing TOMOYO, though. It should be a no-op. Is there some >>>>> situation where this is not true? >>>> There should be no problem except some TOMOYO messages are printed. >>> Okay, so I should send my latest version of the patch to James? Or do >>> you explicitly want TOMOYO removed from all the CONFIG_LSM default >>> lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry >>> the latter will lead to less testing of the stacking.) >>> >> My approach is "opt-in" while your approach is "opt-out". And the problem >> here is that people might fail to change CONFIG_LSM from the default value >> to what they need. (And Jakub did not change CONFIG_LSM to reflect >> CONFIG_DEFAULT_SECURITY_APPARMOR from the old config.) Thus, I suggest >> "opt-in" approach; which includes up to only one legacy major LSM and allows >> people to change the default value to include multiple legacy major LSMs. >> >> You can propose your latest version. If SELinux/Smack/AppArmor people >> prefer "opt-out" approach, I'm fine with "opt-out" approach. > > In the long haul we want people to use CONFIG_LSM to set their > list of modules. Providing a backward compatible CONFIG_DEFAULT_SECURITY_BLAH > makes some sense, but it's important that we encourage a mindset change. > Maybe with CONFIG_DEFAULT_SECURITY_LIST with a a full list, which uses the > value from CONFIG_LSM, and make it the default? >
Hi, I'm still confused. Does this mindset change include removing support of SECURITY_DAC? If so, where was this discussed and decided? And if so (again), that feels like enforcing some kind of policy in the kernel. thanks. -- ~Randy