Re: Common header for security blobs

sdsat_private

On Thu, 6 Sep 2001, Lachlan McIlroy wrote:

> I was just hit with the idea of having a common header
> structure in all security blobs.  What happens when
> module stacking is used and a module gets a security blob
> that was created by another module?  Will it clobber the
> blob or get confused?  Even if it knows that the
> information within the blob is meaningless, how does it
> put it's information in the blob without messing up the
> other module?  We could manage multiple security policies
> by keeping a list of security blobs with each kernel data
> structure.  Information that could be common to all
> security blobs would include a locking mechanism.  A
> union of various types of locks will allow for the
> flexibility to select the lock you need without using too
> much memory.  Information that could be module specific
> would include the module id so a module can find its
> security blob in the list of blobs.
> 
> Any other reasons for or against this idea are welcome...
> but 'general reasons' will be frowned upon.

If you look at the SELinux module, you'll see that we put a magic number
at the beginning of each of our security blobs and that our precondition
functions test this magic number in an attempt to verify that the blob was
allocated by our module.  This magic number is the module id.  Of course,
that only works if other modules do the same.  That topic was raised  
earlier on the list, but there didn't seem to be a consensus about using a 
common header.  

IMHO, if we really want to support easy stacking of multiple modules,
then we do need such a common header with at least a module id and a
list pointer (a struct list_head) for chaining multiple security blobs
on the same kernel data structure.  That would allow modules to be written
in a general way to set and get their own security blob for a given kernel
object without interfering with other modules.  Otherwise, it seems like
chaining modules will require customization to each module being chained
together.  The most obvious example would be if we were to move the
capability fields into the security blob and wanted to chain our modules
with the capabilities module.

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

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