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

pollardat_private

jmjonesat_private:
> On Tue, 5 Jun 2001, Stephen Smalley wrote:
> 
> > 
> > On Tue, 5 Jun 2001 jmjonesat_private wrote:
> > 
> > > I don't see how NOT having two sets of hooks is possible, here, without 
> > > closely examinining each and every possible implementation of each and 
> > > every hook.... past, present, and future.
> > 
> > I'm not sure what you mean.  Consider fs/namei.c:permission.
> > Suppose that we 
> 
> Here's the problem... who's "we", the module developer?  then kernel
> developer?  The LSM interface project?  By breaking it out explicitly,
> you put it in the hands of the module developer without imposing the 
> "consensus" upon security policy.  Any other way, you force every module 
> developer to conform to "the will of the whole"... thereby (goddess, I
> hate to use this word, since Billy G has tainted it) restricting
> innovation.
> 
> > decide that we would like to make the permission()
> > hook authoritative (i.e. it can grant what would be denied by DAC
> > or it can deny what would be granted by DAC) rather than merely
> > restrictive.  So we add a parameter to the permission() hook
> > that expresses the kernel decision, and change the permission
> > function to the following:
> > 
> > int permission(struct inode * inode, int mask) 
> > {
> > 	int retval;
> > 
> > 	if (inode->i_op && inode->i_op->permission) {
> > 		lock_kernel();
> > 		retval = inode->i_op->permission(inode, mask);
> > 		unlock_kernel();
> > 	} else {
> > 		retval = vfs_permission(inode, mask);
> > 	}
> > 	return security_ops->inode_ops->permission(inode, mask, retval);
> > }
> > 
> > Now the permission hook function is authoritative - it can
> > be restrictive or permissive. 
> 
> That's true, as far as it goes, but it prohibits anybody from wanting 
> that from using it, and forces any who DON'T, to accept it.  By dividing
> the issue into two hooks, you can allow two different solutions in the 
> original design, as follows:
> 
> 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 
> 
> // 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);
> }

Your first and second case are equivalent except where the
security_ops->p->inode_ops->permission call may return <0 or <= 0.

Why bother calling the function twice. The function will return either <0
or <= 0, and can determine on its own whether restritive or permissive
aspects are to be done.

Personally, I would also like the last case moved into the module too.
After all, it does implement a "security policy.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollardat_private

Any opinions expressed are solely my own.

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