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

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

((YES GREG K-H, this example is NOT "perfect style"))(G)

The difference is important.  My version allows preservation of the
intrinsic kernel logic IF more restrictive rejections aren't in place OR
more permissive allowances aren't in place.  Leaving the kernel logic in
the middle. If restrictive checks return "okay as long as the kernel
checks pass", we're in.  If the permissive checks return "okay but CHECK
with the kernel", we're in, or "OKAY, IGNORE THE KERNEL" we're also in.

This is TOTALLY non-invasive to the kernel restrictions, I THINK, but
allows short circuiting around them in either case.

This leaves either permissive or restrictive able to "bow to the kernel", 
if desired, I think, but imposes NO overhead to either.

Is a >kernel and <kernel solution.... leaving the existing kernel in the
middle.

With your version, the "intrinsic" checks are performed no matter what, 
and there's no "hook" to potentially override them authoritatively either
way, without a "central LSM project" decision to allow it.  

> 
> --
> Stephen D. Smalley, NAI Labs
> ssmalleyat_private
> 

Of course, subject to smarter-than-me review,
J. Melvin Jones

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