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

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

Magosányi Árpád wrote:
> A levelez?m azt hiszi, hogy Dr.Ir. D.J. Out a következ?eket írta:
> 
>>\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}
> 
> 
> I guess that the goal of ACF is to have those operations which
> cannot be handled within the boundaries of information flow control
> modell. It means that you cannot restrict it to a few operations,
> because real life would not bear it. You also cannot restrict it
> to abstract operations with well-defined semantics, because we are
> talking about real life operations.
> 
> I guess that the question with your PRINT operation is whether
> all effects of the operation are documented. If the developer documents
> that PRINT will place your document world-readable in /var/spool/whatever,
> publish it on wikipedia.org, and send a letter in your name to your boss in which
> you ask him to fire you, then -provided that the PRINT operation does
> work in the mentioned way- it should pass the evaluation.

If I write a Swiss banking PP with one "main" SFR (and a bunch of 
supporting SFRs) "Only the owner of a bankaccount can see that 
bankaccount", have a TOE evaluated to that PP, and only when I buy the 
TOE and have to read the manual to see that it publishes these 
bankaccounts verbatim on wikipedia.org, I have a problem with my standard

It then raises the question: Under this interpretation, in which case 
would using FDP_ACC ever be useful/non-misleading in a PP?

I think that we should make a distinction between the requirement level 
(with abstract operations) and the implementation level (with real-life 
operations). So the TOE should meet the abstract operations no matter 
how it chooses to implement those operations in reality.

So if I have "only owner can READ bankaccount", this PRINT operation 
would cause the evaluation to fail.

Then again, as you say below, this starts to look like information flow 
control.

> The problem in your example was that not all (side) effects were
> documented clearly, which brings up the question of how they should
> be spotted out in a methodological manner. I have the vague feeling
> that if any methodological manner exists, it will include the concepts
> of information flow control. Which might or might not lead to the
> conclusion that ACF is useless.

But when I'm writing the requirements, I cannot document all 
side-effects in the implementation becuase I don't know what the TOE 
will look like.

> This brings up my observation that ACF is actually used in the following
> areas:
> 1. -to have object ownership and similar arbitrary security attributes which
> 	often bear only informational function in the long run.
> 	This is mainly the area of bad design, which we should live with
> 	nevertheless.
> 2. -for the sake of role separation, or to amend badly thought out role
> 	models. This is the area of FMT_SMR actually.
> 3. -to build information flow control measures on it on the TOE above
> 	the one in question. It is FPT_SEP and FPT_RVM, but for the
> 	TOE above it.

I don't agree with the second sentence of 1 (especially the part after 
the comma).
I'm not sure I understand 2.
I need to think more about 3

DJ




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