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

jmjonesat_private

On Tue, 5 Jun 2001, Chris Wright wrote:

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

Actually, yes. Since we want "failure" "success" and "let the kernel
decide", and the error returns (i think) are all <0, success is 0, and 
>0 is not used, we have a whole group of possible return values not
covered, don't we?

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

My intention was to create a three state return condition. 

1) restrictive can return NO, it's no.  If it returns "the kernel decides"
   then it's the kernel's way. If it returns "don't care", it enables the
   permissive check.

   Because this comes before the permissive check, the permissive check 
   will never get control unless it's allowed by the restrictive check.

2) permissive can return YES, and it's YES. If it returns anything else
   the kernel decides. 

3) If the restrictive hook isn't implemented, it returns "DON'T CARE",
   the permissive hook returns "DON'T CARE" (which is a different value
   in the logic below, but that can probably be fixed) and the original
   kernel checks are in control.

(by "kernel decides" i mean "original virgin kernel logic")

There are three separate areas: our permissive, our restrictive, and the 
original/prestine logic.  By thinking tri-state, we allow any combination 
of the three, EXCEPT, by putting the restrictive FIRST it controls the 
the permissive function.

I admit I my example didn't exactly reflect this (the problem with "stream
of consciousness" coding), 

If we clearly assign 
  For restrictive_ops
  <0  as being a rejection (regardless of kernel opinion)
  0   as being "not implemented" or "don't care"
  >0  as being "use kernel value"

and 

  For permissive_ops
  <0  as being "not implemented"
   0  as being "permit"
  >0  as being "use kernel value."

I think I'm speaking "code" more correctly with the following...
apologies.

int permission(struct inode * inode,int mask)
{
        int retval;

// Total restrictive authoritative control (r is the restrictive group)
// restrictive hooks can say NO, DON'T CARE, or FORCE THE KERNEL CHOICE.
// If it can never return ZERO, permissive hooks are *disabled*.

        if (retval=security_ops->r->inode_ops->permission(inode,mask)<0)
	{
                return retval;
        }
        else

// Permissive authoritative control (p is the permissive group)
// Permissive hooks can say "yes" or leave it to the Kernel logic.

        if (
             !retval  
             &&
             !retval=security_ops->p->inode_ops->permission(inode,mask))
           )
	{
                // YES or Kernel.  No gets KERNEL.
                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);
}

I hope I got it right.  If I didn't, I give up.

The value, I think, is to allow an easily verifiable system
for restrictive control, allow permissive control if the 
restrictive side "enables" it, and allow a push (after the fact)
to the original logic by either IF DESIRED, without forcing it 
to be done every time in advance.   

> 
> -chris
> 

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