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

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

There is a reason why I'm not addressing process memory buffer(s), disk
read/write caches, etc.

I see a PP as something that says: "Build me a box that does X". I don't 
care if you use files, buffers, or coconuts to store data in. I don't 
care whether it uses pigeons, fiberoptics, or the Hubble Telescope to 
communicate". As long as it does X.

===ALERT: SILLY EXAMPLE AHEAD ====

So, I'm a personnel officer. I have personnel records. Read access to 
these is to be restricted to only the user they are associated with.

I want to write a PP for it. Because I love my personnel, I'll evaluate 
anything that comes out on EAL7+

I have specified lots of stuff on files/buffers/caches etc.,

Now a developer comes up who creates the TOE entirely from ropes and 
pulleys and lo and behold it appears to meet the PP (kinda easy as ropes 
and pulleys have no files/caches/buffers)

Only the evaluators find out that after accessing a personnel record, a 
publicly visible rope in the hallway contains knots that spell out half 
of the personnel record in morse code.

Ha says the developer! That'll teach you to forget about those 
ever-so-important knots in Morse code in the PP.

Conclusion: You cannot foresee all possible implementations. PPs should 
therefore support implementation-independent specifications that work 
for all possible implementations.

Trying to improve your FDP_ACC by moving it close to the implementation 
will therefore probably not work.

DJ

Open question: The personnel record problem above is one of the simplest 
access control problem in existence. Can it be modelled with FDP_ACC/ACF 
or not?




Hal W Forsberg wrote:
> 
> I believe that your <vague idea> has a low-level consideration that needs
> to be
> addressed.
> 1) What is your exact definition of the data - the original values stored
> in the
> container, or is the PRINT function using a "read" copy of the data?
> 
> In this situation I assert that the function has not violated/broken/etc.
> the
> requirement - the simple PRINT function has not performed any of the
> operations  "change, modify, cause to be changed,  substitute, or alter
> this data."
> => there must be a requirement(s) addressing the "processing" of data if
> you wish
> to "extend" the security function. NOTE: you and others never addressed
> other
> similar constructs in this example such as 
> 
> Halvar Forsberg
> Senior Evaluator
> CSC Common Criteria Testing Laboratory
> 132 National Business Parkway
> Annapolis Junction, Maryland 20701
> (240) 456-6228
> hforsber@csc.com
> 
> 
> ----------------------------------------------------------------------------------------
> 
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery. NOTE: Regardless of content, this e-mail shall not operate to
> bind CSC to any order or other contract unless pursuant to explicit written
> agreement or government initiative expressly permitting the use of e-mail
> for such purpose.
> ----------------------------------------------------------------------------------------
> 
> 
> 
> 
>                                                                                                             
>                       "Dr.Ir. D.J.                                                                          
>                       Out" <out                To:      Multiple recipients of list <cc-cmt@nist.gov>       
>                       @itsef.tno.nl>           cc:                                                          
>                       Sent by: cc-cmt          Subject: Re: I-0451: When To Use IFF/IFC And ACF/ACC         
>                                                                                                             
>                                                                                                             
>                       03/10/2004 05:00                                                                      
>                       AM                                                                                    
>                       Please respond                                                                        
>                       to cc-cmt                                                                             
>                                                                                                             
>                                                                                                             
> 
> 
> 
> 
> 
> And after rereading this, a 2nd answer to the same message (Sorry)
> 
> I think that this distinction between requirements and mechanisms is
> what I'm trying to express.
> 
> And SFRs should be *requirements*. So where Information Flow is an
> actual requirement expressing user needs, ACF may be something much
> closer to an implementation.
> 
> \begin{vague_idea}
> To move ACF back to a requirement, perhaps ACF could be modified to have
> only a few abstract operations, so the semantics of these operations
> would be clear:
> - <create>, <read>, <modify>, <delete>
> and these would cover all actual operations in the implemented TOE
> 
> so in the earlier example, the actual operation PRINT would have
> vulnerabilities if it left something in /var/spool for people to <read>
> A TOE implementing PRINT in that way would not be certified.
> \end{vague_idea}
> 
> 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.
>>
>>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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



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