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

["Dr.Ir. D.J. Out" <out@itsef.tno.nl>]

Gary Stoneburner wrote:
> 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.

Dear Gary,

This helps me a lot (if only to find out whether I am talking gibberish) .
I guess my question is now:

I have a PP that defines access control on controlled containers.

Am I now allowed to build a TOE that contains uncontrolled containers 
and ways to move content from controlled to uncontrolled containers 
thereby seeming to circumvent the access control yet claim conformance 
to the PP?

Where would this fail? If not, should it fail?

DJ




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