Quoting Stephen Smalley (sds@private): > On Tue, 2005-06-07 at 23:26 -0500, serue@private wrote: > > The fact that stack-noselinux outperforms noselinux shows that stacker > > has (at worst, haha :) negligible performance impact. Profiling data > > has shown security_get_value to be the main bottleneck. > > So, to be precise, it has negligible performance impact if you have no > real users of LSM (i.e. no users of the security fields, just > capabilities), and some (but possibly not large) performance impact if > you have a real user of LSM like SELinux, right? Right. > If you are going to have a stacker, then it only makes sense to allow > sharing of the security fields IMHO. Not clear that these particular > modules are good motivating examples however, given that a) they aren't > upstream, b) they likely only need to associate their own data with a > small subset of inodes, thus a hash table may be appropriate, and c) at > least ima seems to have been rejected as a legitimate user of LSM and > the others may run into similar complaints (don't know about evm/slim as > it isn't released AFAIK). Oh, I've finally gotten some more information on slim/evm. The code hasn't yet been released, but is expected to be released in 3Q (ie hopefully very soon now). There is a pdf presentation at http://www.acsac.org/2004/workshop/David-Safford.pdf. The slim module performs integrity measurement, while evm does enforcement. In this way the enforcement module is easily replaceable. By stacking slim, evm, and selinux, evm would enforce of integrity of selinux context labels and file data. > > 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. > > Submitting it to lkml for comments seems reasonable to me. Great - re-basing against 2.6.12-rc6 first, then will send it out. thanks, -serge
This archive was generated by hypermail 2.1.3 : Wed Jun 08 2005 - 08:54:31 PDT