Re: [RFC] [PATCH] Replace security fields with hashtable

From: Chris Wright (chrisw@private)
Date: Fri Oct 29 2004 - 09:02:13 PDT

* Mimi Zohar (zohar@private) wrote:
> >> I think it is really important to be able to share the hooks and the
> >> associated
> >> security data pointers in a logical and coherent fashion.  For this
> reason,
> >> it makes
> >> sense to have stacker be the hook owner and all LSM security modules
> >> writing to it.
> >> None of the LSM security modules, other than perhaps Stacker, should be
> >> builtin, but
> >> should be loaded in the initrd.
> >This makes sense iff you intend to use more than one module.  For the
> >cases where you don't, it's pure overhead.  See the problem?
> True, but what are the options?   Not providing support for sharing the
> hook and data pointers, doesn't sound like a viable option.  So there are
> two issues:  overhead and ease of coding for both with and without stacker.
> To solve the ease of coding, we could define a Stacker API to access the
> security field.  To solve the overhead issue, we could define a compile
> time option indicating whether or not to use Stacker.  This option would
> include a definition of the Stacker API to always return the security
> field.  For example,

That's pretty close to what the efforts thus far are doing.

Linux Security Modules

This archive was generated by hypermail 2.1.3 : Fri Oct 29 2004 - 09:02:31 PDT