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

augustat_private

On Wed, Jun 06, 2001 at 09:20:31AM -0400, jmjonesat_private wrote:
> On Wed, 6 Jun 2001, Jesse Pollard wrote:
> > 
> > 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.

This seems to me like if could cause some problems.

Imagine this pseudocode for open:

open()
{
    if ( restrict_func(state) ) goto fail; 

    /* What if the state changes here? */

    if (  permit_func(state)  ) goto succecss;

    original-unix-dac-logic(state)
    ...
    sucess:
    ...
    fail:
    ...
}

Scenario: Chinese wall policy. I'm a consultant and I can't work on more than
one of the banks we have as customers. 

Permissive rule: Can read files in compartment banking.
Restrictive rule: Can't have access to more than one of the banks in 
compartment banking.

I was recently hired from a competing consulting firm, where I worked 
with bankB.

The file I'm trying to open is marked ( Compartment:banking, Project:bankA)

From the beginning I have no special rights, and the open() will fail because
of the normal DAC permissions.

But between the restrict and permit calls the security admin assigns me the 
label (Compartment:banking, HasWorkedWith:bankB). 

What happens here is that I get to do something that violates _both_ the 
policy-states I have had. (The first one should have failed the DAC, the 
second one should have failed because I've worked on bankB.)

The checks must be atomic.
This can of course be arranged, but it means that the LSM must keep some 
kind of lock between the calls instead of just within one call if it had 
been just one function call.

Am I missing something?

/August, yeah, it's kind of a strange example, but it was the best I
         could come up with right now.
-- 
Bj|rn Augustsson      DCE/DFS Sysadmin     IT Systems & Services
Chalmers tekniska h|gskola     Chalmers University of Technology

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