Re: Extending a Security Module

chrisat_private

* jmjonesat_private (jmjonesat_private) wrote:
> On Tue, 22 May 2001, Chris Wright wrote:
> 
> > Second, what do you do when you _both_ want to access the security blob?
> > Copying things in and out of the security blob isn't too nice, nor is ugly
> > casting with special purpose structs.  I don't think we can go this route.
> 
> Perhaps I was unclear.  The second security_ops structure is in NO WAY
> the problem of the kernel proper.  The hooks call the first registered,
> always, but if a module wants to provide extensions, it just saves the
> vector and IN ITS FUNCTIONS (the one's registered) invokes those at will.
> The MODULE allows extension calls, or not.  If a field in the structure is
> passed that is NULL, the module doesn't replace it's own code... in fact,
> it NEVER *must* replace its own code, just do a "call" to the newly
> registered function when it is appropriate.  Think of it as a "second
> set of hooks" in the module, rather than anything in the kernel proper. It
> could also fail if a "nonreplacable" pointer was replaced.  This is
> TOTALLY up to the module in place, since failures of the FIRST
> register_security() would pass the structure down the chain.
> 
> The subsequently registered "security_ops" structure is kept in the
> module, not the kernel, so it must be invoked from there... UNLESS the 
> module decides (by whatever policy) that it's "unworthy" and the new
> module should be "first", then it can unregister the "valid" structure,
> and replace the new one, and subsequently call "register_security()" in
> hopes of getting higher on the list.

load both modules.

modprobe my_module
modprobe capability_plug /* security_ops->register() will get called */

start a new task
fork()

create a security blob for the new task
security_ops->task_ops->alloc_security(task)

my_module_task_alloc(task)
{
	task->security = kmalloc(sizeof(my_big_security_blob, GFP_KERNEL);

	/* this will overwrite the opaque security blob, so you'd
	 * better save off your stuff.  how do you combine them back
	 * in general? 
	 */
	my_registered->task_ops->alloc_security(task); 
}

maybe you only care about the registered ops for the capable() call.

my_module_capable(cap)
{
	/* this implicitly expects current->security to be a 
	 * capabilities specific opaque blob, 
	 */
	my_resgistered->capable(cap);	
}

My point is you have to accomadate two modules needs in one opaque blob.
So the registrar module must know the details of the opaque blobs of the
registered module.

-chris

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