Re: [PATCH v12 0/9] LSM: Multiple concurrent LSMs

[Casey Schaufler]

On 1/7/2013 7:01 PM, Stephen Rothwell wrote:
> Hi Casey,
>
> On Mon, 07 Jan 2013 17:54:24 -0800 Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
>> Subject: [PATCH v12 0/9] LSM: Multiple concurrent LSMs
>>
>> 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. 
>>
>> A level of indirection has been introduced in the handling of
>> security blobs. LSMs no longer access ->security fields directly,
>> instead they use an abstraction provided by lsm_[gs]et field
>> functions. 
>>
>> The XFRM hooks are only used by SELinux and it is not clear
>> that they can be shared. The First LSM that registers using
>> those hooks gets to use them. Any subsequent LSM that uses
>> those hooks is denied registration. 
>>
>> Secids have not been made shareable. Only one LSM that uses
>> secids (SELinux and Smack) can be used at a time. The first
>> to register wins.
>>
>> 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.
>>
>> Some hooks don't fit that model. setprocattr, getprocattr,
>> and a few others are special cased. All behavior from
>> security/capability.c has been moved into the hook handling.
>> The security/commoncap functions used to get called from
>> the LSM specific code. The handling of the capability
>> functions has been moved out of the LSMs and into the
>> hook handling.
>>
>> The /proc/*/attr interfaces are given to one LSM. This
>> can be done by setting CONFIG_SECURITY_PRESENT. Additional
>> interfaces have been created in /proc/*/attr so that
>> each LSM has its own named interfaces.
>>
>> Signed-off-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>
> Let me ask Andrew's question:  Why do you want to do this (what is the
> use case)?  What does this gain us?

There has been an amazing amount of development in system security
over the past three years. Almost none of it has been in the kernel.
One important reason that it is not getting done in the kernel is
that the current single LSM restriction requires an all or nothing
approach to security. Either you address all your needs with a single
LSM or you have to go with a user space solution, in which case you
may as well do everything in user space.

Multiple concurrent LSMs allows a system to be developed incrementally
and to combine a variety of approaches that meet new and interesting
needs. It allows for systems that are based on an LSM that does not
meet all of the requirements but that can be supplemented by another
LSM that fills the gaps. It allows an LSM like Smack that implements
label based access controls to remain true to its purpose even in the
face of pressure to add controls based on other mechanisms.

I have had requests for running Smack and AppArmor together Tetsuo has
long had need to put SELinux and TOMOYO on the same box. Yama was
recently special cased for stackability.

We are looking at security from different directions than ever before.
What good is a UID on a cell phone? I hear complaints about Android's
"abuse" of the UID. With the option of independent groups creating
smallish LSMs and integrating them by stacking we have the ability to
make the security systems modern devices require using a architecturally
clean model rather than hijacking existing mechanisms that work a
little bit like what you want to do.

I used to believe in a single, integrated security module that addressed
all the issues. Now that Linux is supporting everything from real time
tire pressure gauges in tricycles to the global no-fly list that just
doesn't seem reasonable. We need better turn around on supplemental 
mechanisms. That means collections of smaller, simpler LSMs instead of
monoliths that only a few select individuals or organizations have any
hope of configuring properly.

The topic has been discussed at the past couple of Linux Security Summits
and the only real issue has been who would grind out the code. All of
the existing LSM maintainers are open to stacking. 

> Also, you should use unique subjects for each of the patches in the
> series.
>
Yes, I noticed I'd mucked that up as they flew into the ether.

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