Re: Common header for security blobs

sarnoldat_private

On Fri, Sep 07, 2001 at 12:51:57AM +0000, David Wagner wrote:
> Yup.  You can probably clean this up a bit, too.  If you replace use of
> current->security in each base module by some appropriate abstraction,
> a multiplexor can call both modules in succession (and respond to that
> abstract interface appropriately).

I don't like replacing [object]->security with getsecurity([object]),
mainly because adding another level of indirection in every hook that
wants a security blob is going to get expensive. [0] Perhaps there is
some method that could be used at compile time to make it all disappear
into the code, but if these sorts of things have to be run at runtime,
our performance numbers are going to drop. Before deciding to do this,
it would be nice to know how much we would have to pay.

One idea I had last night, one that I haven't thought through enough to
know how silly it is, is for the modules to keep track of the blobs
themselves. They could use the [object]->security field as an input to
a hash function that computes an array location that contains a pointer
off to their own individual security blob, in memory handled entirely by
the module.

My thinking: modules that wish to play nicely and stack will pay the
associated performance penalties. Modules that don't care much for
stacking aren't penalized and can use [object]->security wherever they
wish.

Of course, only modules that play well together can be stacked with this
(possibly stupid?) idea -- but that is probably for the best anyhow.

The nice thing, if I am not mistaken, is that nothing needs to change
from our current model for this to work. A multiplexor module needs to
be written to do sane things with [object]->security pointers, such as
use a counter for their values rather than allocating storage someplace
for the pointer to point to -- but a multiplexor module would have to be
written for stacking in any case.

Any comments?

Thanks

[0]: A secondary reason is that get* and set* functions look and smell
a lot like Java, and I came here because I got tired of Java.. :)

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module