Re: I-0451: When To Use IFF/IFC And ACF/ACC


But for integrity I have nothing like information flow.

How would I code with SFRs in a PP:

The TOE will have a container containing data. This data may only be 
changed by user X.

Nobody else is allowed to change, modify, cause to be changed, 
substitute, or alter this data in any way in such a way that all TOEs 
meeting this PP actually don't do this?

DJ

YOKOTA HIROFUMI wrote:
> Certainly, "Subset access control(FDP_ACC.1)" has vulnerabilities.
> 
> Also, we can't say  "Complete access control(FDP_ACC.2)" is secure, 
> since it does not meet the need if the restrictions ( rules ) are not 
> applied correctly to all the controlled subjects, objects and operations.  
> 
>  
> 
> So, I agree with Dirk-Jan.
> 
>  
> 
> We can say, attributes associated with a container are always associated 
> with the content.
> 
> But, attributes associated with a content are not necessary associated 
> with the container.
> 
>  
> 
> I think, this means that attributes based rules of information flow 
> control covers what attributes based rules of access control can not 
> cover.   
> 
>  
> 
> Yokota
> 
>     ----- Original Message -----
> 
>     *From:* Gary Stoneburner <mailto:gary.stoneburner@nist.gov>
> 
>     *To:* Multiple recipients of list <mailto:cc-cmt@nist.gov>
> 
>     *Sent:* Wednesday, March 10, 2004 3:27 AM
> 
>     *Subject:* Re: I-0451: When To Use IFF/IFC And ACF/ACC
> 
> 
>     I think you are on the right track with the concept that ACF is a
>     mechanism trying to meet, not the actual need (at least in some, and
>     perhaps most) cases.  Even so, ACF might be the practical, best
>     choice for a mechanism to be implemented.
> 
>     You are saying, I think, that we do NOT have an access control
>     requirement.  We have a "only certain subjects can read this
>     information" requirement for which access control has been used as
>     the means of achieving the need.  If the information is contained
>     only in controlled containers then ACF can accomplish the task. 
>     This, however results in restrictions for all information that the
>     container might contain and does not meet the need if the
>     restrictions are not applied correctly to all controlled
>     containers.  Also the basic assumption (only controlled containers)
>     may be false and the need might not be met if there are uncontrolled
>     containers that may contain this information.
> 
>     By abstracting the need up, you see can better uncover where the
>     potential holes are in the coverage.
> 
>     Cheers,
>     Gary
> 
>     PS:  No - the legality of drug in the Netherlands did not come to
>     mind (until you mentioned it :-)
> 
>     At 11:21 AM 3/9/2004, you wrote:
> 
> 
>>     Gary Stoneburner wrote:
>>
>>>     DJ,
>>>     I see the interpretation as providing guidance on how to make
>>>     decisions on ACC/ACF verses IFC/IFF.  This is in contrast to an
>>>     interpretation giving the requirements on how to use these.
>>
>>
>>     True and valid. I only jumped on this with my question as it
>>     a) seemed to be relevant to it
>>     b) gave me a chance to get knowledgeable feedback
>>
>>     As you may know, my new work item in the CCIMB is Terminology or
>>     "What does it all mean?".
>>
>>     I have provided a solution for a part of it (ASE/APE) but I'm now
>>     working on a few others: TOE/TSF/SFP/SPM etc.
>>
>>     One of the things that I'm trying to reach is that the SFRs
>>     determine "This is secure" for a given evaluation. They should
>>     therefore be very clear in what they mean, and through this
>>     disucssion I hope to gain such clarification.
>>
>>>     You seem correct in that the issue you raise, it is not access to
>>>     a container, but the protection of certain data wherever it is
>>>     contained. 
>>>     The access rights to the container are derived from this data
>>>     (and apparently this derivation is time sensitive) .  It may be
>>>     possible to fix the access rights (ACC/ACF perhaps).  Yet this
>>>     would still remain a solution to access based upon data in the
>>>     container, and not fundamentally access based upon the
>>>     container.  The latter would, in that case, only be a means of
>>>     accomplishing the former and as it is not really what is wanted,
>>>     might have some undesirable (and perhaps unacceptable) consequences.
>>
>>
>>     So just to provide some insight in what I'm trying to reach
>>     (although your conclusion from this is probably that it is a bad
>>     things that drugs are legal in the Netherlands :) )
>>
>>     If you are specifying confidentiality in a TOE, you are utterly
>>     non-interested in confidentiality of a container. Who cares who
>>     can do what operations on a container: from the confidentiality
>>     side of things you are only interested in the confidentiality in
>>     the contents of that container.
>>     So on a high-level of abstraction, for confidentiality only
>>     information flow is important.
>>
>>     If you persist using the access control policy for
>>     confidentiality, you run into the following problem:
>>     If the policy says:
>>     A is not allowed to READ file X,
>>     B is allowed to READ file X
>>
>>     You are only saying something about the READ operation as defined
>>     for files.
>>
>>     An implementation where whenever B performs READ on file X, as a
>>     side effect the contents of the file is displayed on all terminals
>>     of the TOE (including that of A) is not in conflict with the
>>     policy as A did not perform the READ operation on the file. A can
>>     read it (i.e. gain knowledge of its contents), but A cannot READ
>>     it (i.e. use the READ operation).
>>
>>     So it would seem that using the access control policy will almost
>>     always cause problems with confidentiality as it is doubtful
>>     whether this displaying TOE is really what was meant by the use of ACC
>>
>>     I think I can pose a similar problem for integrity, which then
>>     raises the question, when *does* one use ACC....
>>
>>     Now I think this is caused by the problem that ACC does not specify:
>>     - whether you do concrete operations on concrete objects and are
>>     not interested in anything else (there is a difference between
>>     READ and read as defined above)
>>     - whether you do abstract operations on abstract objects (in which
>>     case there is no difference anymore between READ and read)
>>
>>     Am I still making sense?
>>
>>     Dirk-Jan
>>
>>     -- 
>>     TNO ITSEF BV
>>     P.O. Box 96864          tel +31 70 374 0304
>>     2509 JG The Hague       fax +31 70 374 0651
>>     The Netherlands         www.commoncriteria.nl
>>     <http://www.commoncriteria.nl/>
>>
>>
>>
>>
>>
>>
>     **************************************************************************
>     * Opinions expressed are not intended to reflect an official position
>     **************************************************************************
>     * Gary Stoneburner
>     * Computer Security Division, National Institute of Standards &
>     Technology
>     * 100 Bureau Drive, Stop 8930, Gaithersburg, MD 20899-8930         
>     * Phone: 301-975-5394, FAX: 301-948-0279, Email: Stoneburner@nist.gov
>     * http://csrc.nist.gov/staff/stoneburner/gshome.html
>     **************************************************************************
> 
> 



-- 
TNO ITSEF BV
P.O. Box 96864          tel +31 70 374 0304
2509 JG The Hague       fax +31 70 374 0651
The Netherlands         www.commoncriteria.nl
Date Index | Thread Index | Problems or questions? Contact list-master@nist.gov