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@xxxxxxxxxxxxxxxx> > > 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. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
