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

jmjonesat_private

On Wed, 6 Jun 2001, Jesse Pollard wrote:

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

First call is to security_ops->r... (the restrictive function) and the 
second is to security_ops->p... (the permissive function) and I admit the 
first version fell short of what I'd meant to say.  By separating the 
functions and only listening to the result (NO or YES) that is inherent 
in either, you clearly separate the two functions.

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

I would, too, but now I have to concede that is probably more invasive
than strictly necessary, and I can't disagree with the argument that, 
when it comes to changing the core kernel code, "less is more" in a lot
of ways.

> 
> -------------------------------------------------------------------------
> Jesse I Pollard, II
> Email: pollardat_private
> 
> Any opinions expressed are solely my own.
> 

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