Linux 5.1-rc2

[Casey Schaufler]

On 3/27/2019 3:55 PM, Randy Dunlap wrote:
> 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?

No.

>    If so, where was this discussed and decided?

linux-security-module at vger.kernel.org on threads related to security
module stacking. It's easy to get the same result with a CONFIG_LSM
that includes none of the SELinux, Smack, TOMOYO or AppArmor.

> And if so (again), that feels like enforcing some kind of policy in the kernel.

Again, not so. It's a change from "The not-more-the One Major Module" to
"Whatever set of policies works for you". The NULL set is completely
supported. The current flap is that it's more difficult to express doing
things the old way. Kees and Tetsuo are hashing out how best to support
old .confg files in support of automated tools.


> thanks.