Re: I-0463: Hardware Inclusion In A TOE With FPT_SEP

["Daniel P. Faigin" <faigin@solarium.aero.org>]

On Tue, 16 Jul 2002 14:57:29 -0700, Nir Naaman <nnir@netvision.net.il> said:

> Maybe I misunderstood the guidance, but the guidance says:
>> STATEMENT
>> 
>> All TOE Objectives (which map to Security Functional Requirements)
>> must be met by the TSF. It is not acceptable to meet a TOE Objective
>> by a requirement allocated to the IT environment.
>> 
>> Hence, only if an argument can be made that FPT_SEP is satisfied
>> independent of the hardware would it be acceptable to exclude hardware
>> from the TOE for which FPT_SEP is a TOE SFR.
>> 

> This is very explicit; IF (FPT_SEP is a TOE SFR) THEN hardware-
> must-be-included-in-the-TOE.

> Unless of course an argument can be made that FPT_SEP is satisfied
> independent of the hardware, which the guidance states is not likely
> using current technology.

Correct.

> The guidance goes on in saying:
>> Of particular interest is the FPT_SEP requirement. FPT_SEP.1.1 says
>> "The TSF shall maintain a security domain for its own execution that
>> protects it from interference and tampering by untrusted subjects". If
>> this requirement is allocated to the application TOE, this means the
>> application is 100% responsible for providing such protection,
>> completely independent of the behavior of applications on the
>> underlying abstract machine (operating system, hardware).

> What happens when FPT_SEP is intended to be satisfied by
> a COMBINATION of environment and TOE requirements?

Then you should use explicitly specified requirements to make the
distinction and division between the two clear.

>> With respect to applications claiming FPT_SEP: In order to do so, one
>> must be able to show that the application provides mechanisms that
>> implement FPT_SEP independent of any operating system support. With
>> current technology, however, operating system support is usually
>> required to achieve FPT_SEP, and hence, FPT_SEP should be allocated to
>> the IT Environment (Operational Environment).

> I'll focus my example. A database product might have well-defined
> interfaces with which users interact. A database reference monitor
> enforces a database access control or information flow control policy
> between subjects and objects.

> I would think that this reference monitor should provide FPT_SEP.1,
> i.e. a bad example would be having the same code that parses the
> users' SQL statements also enforcing the access control policy.
> Ideally, this should happen in a separate process context, in order
> to protect it against interference and tampering by untrusted subjects.

> I would have liked to allocate FPT_SEP at the OS level to the environment,
> and ALSO allocate FPT_SEP at the DB level to the TOE. A similar
> convention has been used by the Oracle DBMS.PP, refining the TOE
> FPT_SEP requirement to refer to DATABASE subjects, and ALSO
> requiring FPT_SEP to be satisfied by the operating environment (OS).

> Is this O.K.? Reading the guidance literally, I'm not sure that it is.
> But I do think it should be. Especially when the TOE's environment
> is assumed to be an evaluated OS.

On the surface, based on what you describe, it sounds reasonable to me. It
makes it clear that there is a dependence on FPT_SEP support to be provided by
the environment.

As for use of an evaluated OS: You can dictate that the IT environment is
compliant with a particular PP as a requirement.

> On July 16, 2002 10:51, "Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.com>
> said:

>> Let me reiterate - moving FPT_SEP to the IT environment is generally
>> unproductive since the IT environment cannot effectively protect a TOE
> that
>> does not protect itself. If the TOE provides interfaces, it most likely
>> should be able to claim FPT_SEP in a meaningful and useful way.

> I think this is what I'm trying to say.

And I think this is a valid point, and indicates some wordsmithing is required
at the next NIB meeting. This is why these are posted for review, and why
people should participate in discussions such as this.

Daniel