On Tue, 07 Jun 2005 23:26:39 CDT, serue@private said: > The fact that stack-noselinux outperforms noselinux shows that stacker > has (at worst, haha :) negligible performance impact. Certainly a non-surprising result, but one that you'll need handy to sell it to the lkml crowd. It *does* show that the bulk of the time is in each actual LSM - meaning that sites will be able to choose their own trade-off between security and overhead (somehow, I see selinux+TPM+capstack as being both more bulletproof and bigger footprint than, say, a combo like openwall+realtime ;) > Profiling data > has shown security_get_value to be the main bottleneck. However, > supporting stacker without supporting the sharing of inode->i_security > would be bad for stacking selinux+digsig, selinux+ima, and selinux+ > evm/slim (the tpm-based integrity verification modules), as some of these > modules would have to implement their own hash tables to keep the kernel > object security data. Any great ideas/theories on how security_get_value can be speeded up? > At this point I would like to forward stacker to the lkml for comment. > Please let me know if there are any objections to that. Umm.. if you aren't already doing so, can you drop a fairly generic blurb into Documentation/LSM-stacker.txt discussing the issues of generic function composition, give a straw-man example or two of an "unexpected result", and explain that getting it right is the sysadmin's problem? Probably should also touch on the fact that while just gluing several small modules together probably isn't the best solution theory-wise, for many sites it's "good enough" - not every box that needs an LSM or three needs an SELinux-sized solution (which *does* add into the TCO)... This probably won't fly on lkml unless you specifically use "there are different correct solutions on the cost/security curve" as a selling point....
This archive was generated by hypermail 2.1.3 : Wed Jun 08 2005 - 06:06:24 PDT