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

jmjonesat_private

On Wed, 6 Jun 2001, Bjorn Augustsson wrote:

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

Hrm.  I was under the impression that code running in the kernel was
somewhat "protected" from race conditions.  Perhaps I was mistaken....
anybody?

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

I agree, and if it's possible to suspend the kernel and change data
between the two calls, this is significant and I hadn't thought of it.

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

Well, there's a lock_kernel() call that does something, and various other 
mechanisms that could be used (hard lock, spin lock, logic lock), but you 
have a very good point... and use of any of these may just mess me up
royally in the "more efficient" argument.

> 
> 
> Am I missing something?
> 

Only if I'm not. :)

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

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