Re: Extending a Security Module

jmjonesat_private

On Tue, 22 May 2001, Chris Wright wrote:

> * 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 */

YES.  And at that moment, capabilty_plug can fail OR, if LXEXAMPLE doesn't
WANT to provide extension to any of the non-NULL pointers in the structure
offered, it has already failed.

> 
> 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); 
> }

Yep, but only in the LSMEXAMPLE module, since the structure it only 
registered there.

> 
> 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);	
> }

Hrmmm.  You lost me here.  It WOULD be, for CAPABILITY_PLUG.O, although 
the hooks from the kernel would pass down the chain.  If the hooks
resulted in a failure and passed that back, wouldn't you routine, if
looking for failures, see them?  If your code wanted to be "local", it
could just call the original function (the one who was registered in 
the original register_security() call).

Seems more like an argument for MY point, since putting it in NOW would
prevent this assumption.

> 
> 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.

I don't see this.  If a call to, say, security_ops->permission() from the 
kernel calls the first registered module, and that hooks down to other 
registered modules to determine the correct return code, how does the 
"kernel proper" need to know about it?

> 
> -chris
> 

Not TRYING to be obtuse,
J. Melvin Jones

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

|>------------------------------------------------------
||  J. MELVIN JONES            jmjonesat_private 
|>------------------------------------------------------
||  Microcomputer Systems Consultant  
||  Software Developer
||  Web Site Design, Hosting, and Administration
||  Network and Systems Administration
|>------------------------------------------------------
||  http://www.jmjones.com/
|>------------------------------------------------------

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