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

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

Nir Naaman wrote:
> On Wednesday, March 10, 2004 Dr.Ir. D.J. Out wrote:
> 
> 
>>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
> 
> 
> I'm either a party pooper or just ignorant, but isn't this crying out for a
> reference monitor:
> FDP_ACC.2+FDP_ACF.1+FPT_SEP.2+FPT_RVM.1+ADV_INT.3?
> 
> This combination can EASILY express the requirement that the data IN the
> container can't be changed, modified, altered, substituted, mangled, broken,
> torn apart, whatever by anybody other than user X. Of course, user X can
> create a COPY of the data that can be modified by others, but so what?

This may be. It depends on the exact definition of "security domain of a 
subject" in FPT_SEP

Suppose I walk on a very crowded market. I have a big tin with me, that 
only I can open and nobody else (FDP_ACC). As soon as I open it, other 
people in the market can see what is in the tin.

What I want to be able to do is go into a closed room with no windows, 
open the tin, manipulate its contents, close the tin, and then go back 
on the market.

I may then tell others what is in the tin, but this is my own 
responsbility.

So I guess I'm looking closely at whether the security domain is a 
closed room. The definition in para 434 are not really good enough I think.

It also doesn't help that ACC.2 is circularly defined (The SFP shall 
apply to all objects/subjects in the TSC, where TSC is the list of 
objects/subjects that the SFPs apply to).

So ACC.2 doesn't tell me anything about objects that may not be in the 
TSC (like the aforementioned printer queue)

But I guess I agree that RVM/SEP and ACC.2 can do the job (once clearly 
formulated). INT.3 has no realtion to it (it is the quality of the 
implementation, rather than a specification of the security problem)

Thanks for this,

Dirk-Jan








> 
> What doesn't this combination do? It doesn't guarantee that there are no bad
> information flows THROUGH user x and into the container.
> 
> IFF is nifty, but outside the defense establishment, you can add:
> A.WE_TRUST_USERS_NOT_TO_DO_STUPID_OR_ILLEGAL_THINGS_AND_WHEN_THEY_DO_THEN_TH
> ANK_GOD_WE_ARE_INSURED
> 
> And suddenly: ACF starts looking pretty attractive.
> 
> Or have I totally missed it?
> 
>     Nir
> 
> 
> 
> 
> 



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