Message-ID: <50F4D83E.9050802@schaufler-ca.com>
Date:	Mon, 14 Jan 2013 20:17:02 -0800
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Stephen Smalley <sds@...ho.nsa.gov>
CC:	James Morris <jmorris@...ei.org>,
	LSM <linux-security-module@...r.kernel.org>,
	LKLM <linux-kernel@...r.kernel.org>,
	SE Linux <selinux@...ho.nsa.gov>,
	John Johansen <john.johansen@...onical.com>,
	Eric Paris <eparis@...hat.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Kees Cook <keescook@...omium.org>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v12 0/9] LSM: Multiple concurrent LSMs

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@...aufler-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.


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

Powered by blists - more mailing lists