Re: I-0451: When To Use IFF/IFC And ACF/ACC
- Subject: Re: I-0451: When To Use IFF/IFC And ACF/ACC
- From: "Dr.Ir. D.J. Out" <email@example.com>
- Date: Thu, 11 Mar 2004 11:23:51 +0100
- Content-Transfer-Encoding: 7bit
- Content-Type: text/plain; charset=us-ascii; format=flowed
- Organization: TNO-ITSEF BV
- References: <002301c406e2$3f7a6d20$793816ac@T23>
- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
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?
> I'm either a party pooper or just ignorant, but isn't this crying out for a
> reference monitor:
> 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
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,
> 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:
> And suddenly: ACF starts looking pretty attractive.
> Or have I totally missed it?
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 firstname.lastname@example.org