Re: Extending a Security Module

chrisat_private

* jmjonesat_private (jmjonesat_private) wrote:
> On Tue, 22 May 2001, Chris Wright wrote:
<snip>
> > 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); 
> > }
> 
> Yep, but only in the LSMEXAMPLE module, since the structure it only 
> registered there.

Sure, the kernel hook hasn't changed.  The registrar module code is what is
calling the registered hook, that's not the issue.

The task pointer is in the kernel.  The task->security pointer is in
the kernel.  The module allocates space and assigns the pointer to the
task->security pointer in the kernel.  The registrar and registered modules
both want to own the opaque security blobs.  There is only ONE void pointer.
You have to be prepared to do good housekeeping, that's what I'm trying to
say.

/* invoked when security_ops->task_ops->alloc_security() is called in kernel */
my_module_task_alloc(task)
{
	struct my_big_security_blob *blob;
	my_registered->task_ops->alloc_security(task);
	/* this just assigned a value to task->security 
	 * but wait, I want to add my own per process
	 * security attributes.
	 */
	blob = (struct my_big_security_blob *)kmalloc...
	/* my blob needs to have a blob in it so I can store
	 * their blob
	 */
	blob->blob = task->security;
	task->security = blob;
}

/* invoked when security_ops->capable() is called in kernel */
my_module_capable(cap)
{
	struct my_big_security_blob *tmp = current->security;

	/* do my capable check here */

	/* update the security pointer to be their blob
	 * which I had stored in my blob
	 */
	current->security = tmp->blob;
	my_registered->capable(cap);

	/* now restore everything */
	current->security = tmp;
}

Can you see how you have to be careful when sharing the single opaque blob
between modules?  That's what I'm driving at.  It's not the end of the
world, and what your proposing may be better than what we have now.  But it
is also dangerously close to explicitly supporting multiple modules and
going down a path that we may not be ready to explore.

-chris

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