On Thu, Aug 1, 2013 at 10:51 PM, Casey Schaufler <ca...@schaufler-ca.com> wrote:
> On 7/31/2013 7:48 PM, Balbir Singh wrote:
>> On Thu, Jul 25, 2013 at 11:52 PM, Casey Schaufler
>> <ca...@schaufler-ca.com> wrote:
>>> Subject: [PATCH v14 0/6] LSM: Multiple concurrent LSMs
>>>
>>> Version 14 of this patchset is based on v3.10.
>>> It required significant change from version 13 due to changes
>>> in the audit code. It came out cleaner, especially in the changes
>>> to NetLabel. This version supports all existing LSMs running
>>> together at the same time. The combinations tested most completely
>>> are:
>>>
>>>     apparmor,tomoyo,smack,yama  - Ubuntu
>>>     apparmor,selinux,smack,yama - Fedora
>>>
>> Does this change the way one would develop a new LSM module? I presume
>> it does not
>
> The change that LSM developers need to be aware of is the security blob
> abstraction. Instead of using cred->security, inode->i_security and the
> like the code needs to use lsm_get_cred() and lsm_set_cred() and similar
> functions.
>

OK

>>> I have been unable to figure out how to configure SELinux on
>>> Ubuntu and TOMOYO on Fedora. That's the only reason the list
>>> does not include all five LSMs at once. Combining LSMs that
>>> use networking is tricky, but can be done. There are changes
>>> coming from AppArmor that might make it even trickier, but
>>> that's a problem for the future.
>>>
>>>
>>> Change the infrastructure for Linux Security Modules (LSM)s from a
>>> single vector of hook handlers to a list based method for handling
>>> multiple concurrent modules. All combinations of existing LSMs
>>> are supported.
>>>
>>> The "security=" boot option takes a comma separated list of LSMs,
>>> registering them in the order presented. The LSM hooks will be
>>> executed in the order registered. Hooks that return errors are
>>> not short circuited. All hooks are called even if one of the LSM
>>> hooks fails. The result returned will be that of the last LSM
>>> hook that failed.
>>>
>> This is an important design trade-off. From my perspective I think you
>> might want to revisit this, today it sounds like effective security ==
>> all hooks process and allow the operation. In this world a lack of
>> proper policy/setting can make hooks fail. I've not yet looked at the
>> code, but you might want to revisit this.
>
> The result of an LSM hook will be failure if any of the LSMs
> indicates failure. The key here is that all of the LSM hooks
> get called even if it's known that the overall result is failure.
> This is done because many LSM hooks maintain internal state and
> shortcutting can disrupt that.
>

Thanks for clarifying

Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to