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

From: jmjonesat_private
Date: Tue Jun 05 2001 - 17:22:56 PDT

  • Next message: Chris Wright: "Re: bitkeeper login"

    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
    



    This archive was generated by hypermail 2b30 : Tue Jun 05 2001 - 17:25:12 PDT