Re: permissive vs. restrictive issue and solutions...

chrisat_private

* jmjonesat_private (jmjonesat_private) wrote:
<snip>

> int permission(struct inode * inode,int mask)
> {
>         int retval;
> 
> // Total restrictive authoritative control (r is the restrictive group)
> 
> 	if (retval=security_ops->r->inode_ops->permission(inode,mask)<0) {
>         	return retval;
> 	}
> 	else
> 
> // Total permissive authoritative control (p is the permissive group)
> 
>         if ((retval=security_ops->p->inode_ops->permission(inode,mask))<=0) {
>         	return retval;
>         }
>         else 
> 
How do we ever get here?  Are you suggesting it is possible that the p
group can return <0, 0 or >0?  
> // Original kernel logic here.
> 
>        	if (inode->i_op && inode->i_op->permission)
> 	{
>                	lock_kernel();
>                	retval = inode->i_op->permission(inode, mask);
>                	unlock_kernel();
>                	return retval; 
> 	}
> 
> 	return vfs_permission(inode, mask);
> }
> 

I simply do not understand what you are proposing.  Stephen's
suggestion for the permission() call adds an authoritative hook at the
end.  This way the kernel makes all DAC checks and (as Wagner proposed
in what we were once calling option #3) passes the results of that
check to the module.  At this point the module is making an
authoritative decision.  It can override the permission granted
and deny.  It can override the restriction imposed and allow.

How is your proposal adding any value to Stephen's proposal?  The way I
am reading it (assuming the p functions might return >0) you never
get a chance to _override_ the kernel logic.  And you have doubled the
interface by adding an 'r' group and a 'p' group.  How does having two
groups of hooks allow two different solutions, where one authoritative
hook does not?  I am strongly in favor of a simple uniform interface
that provides the flexibility needed.  I do not believe your proposal is
either simple or flexible (since it doesn't allow overriding DAC checks
without recreating them in your own module).

-chris

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