[lkml]   [2013]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v14 0/6] LSM: Multiple concurrent LSMs
On Thu, Aug 1, 2013 at 10:51 PM, Casey Schaufler <> wrote:
> On 7/31/2013 7:48 PM, Balbir Singh wrote:
>> On Thu, Jul 25, 2013 at 11:52 PM, Casey Schaufler
>> <> 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.


>>> 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


 \ /
  Last update: 2013-08-06 05:41    [W:0.058 / U:3.992 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site