Re: lsm stacker

From: Stephen Smalley (sds@private)
Date: Wed Jun 08 2005 - 06:51:06 PDT

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?

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

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).

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

Stephen Smalley
National Security Agency

This archive was generated by hypermail 2.1.3 : Wed Jun 08 2005 - 09:42:03 PDT