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

[Casey Schaufler <casey@schaufler-ca.com>]

On 1/8/2013 9:47 AM, Stephen Smalley wrote:
> On 01/07/2013 08:54 PM, Casey Schaufler 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@schaufler-ca.com>
>
> Have you run any benchmarks, particularly to compare performance
> overhead in the simple case of a single LSM?
>

Yes. Finally.


I ran a series of micro-benchmarks on the assumption that
we're most concerned with system call performance. I used
lmbench, not because it's the world's greatest benchmark
but because it targets some of the things I care about.
I am perfectly happy to accept suggestions of other benchmarks,
but I make no guarantees that I'll be able to run them.

I ran sets of three runs for each configuration and tossed
any benchmark where I had too great a deviation. I ran one
set on Fedora 17 and another on Ubuntu 12.04. I ran what I
consider some interesting configurations, with both the old
LSM infrastructure and the stacking infrastructure.

I compared the performance for these configurations:

	CONFIG_SECURITY disabled
	CONFIG_SECURITY enabled, no LSM specified
	CONFIG_SECURITY enabled, SELinux enabled
	CONFIG_SECURITY enabled, SELinux and Yama enabled
	CONFIG_SECURITY enabled, Smack enabled
	CONFIG_SECURITY enabled, Smack and Yama enabled

I also ran SELinux + AppArmor + Yama, Smack + AppArmor + Yama
and Smack + AppArmor + TOMOYO + Yama under the stacking
framework, but as I can't run them without it I can't do
comparisons.

I found that with security disabled I got 0.79% worse
overall performance with Fedora but a 0.81% better overall
performance with Ubuntu. The combined was 0.01% better,
so I figure that the methodology looks OK.

On Fedora I found that for all comparable configurations
stacking added 1.23%. For Ubuntu, it was 0.61%.

I am no statistician, and I do not aspire to becoming one. 
I know that my methods were nowhere near clean and were
in fact very noisy. I had to disqualify a good number of
my results because the deviation between runs was too large.