RE: Request for interpretation: treatment of hardware needed by software product

["Knoke, Jim" <Jim.Knoke@GetronicsGov.com>]

I was unable to find the interpretation that TOE functions cannot be
allocated to the environment. Can someone point me at it?

I'm still not clear on why an ST shouldn't be able to allocate portions
of security functionality to the IT environment. Even if SEP and RVM are
included, couldn't I write statements like the following in my ST:
	- the TOE does not include the underlying hardware
	- the underlying hardware constitutes the abstract machine
	- the hardware must provide software with a means to establish
privileged and unprivileged domains
	- the hardware must not allow software executing in unprivileged
domains to create, modify, or destroy data or execution flow in another
domain
	- the hardware must not allow software executing in unprivileged
domains to change the address translation scheme or to expand the set of
addressable memory locations
	- the hardware must not allow software executing in unprivileged
domains to gain hardware privilege
	- the hardware must not allow software executing in unprivileged
domains to directly change the hardware state, except for the values in
general-purpose registers and memory locations that are available to the
unprivileged domains

The original NIB opinion said that hardware must be included in the
*TOE*. Did they mean TSF? I'm happy with TOE since that might allow less
documentation, CM, etc.

 
NIB:
> > One doesn't necessarily have to include the hardware, but
> one does have to
> > show how the requirements are met by the TOE (recall the
> international
> > interpretation that TOE functions cannot be allocated to
> the environment).

James Arnold:

> I'm not sure what international interpretation you are 
> refering to, but I tend to
> agree that the TOE security functions shouldn't be (entirely) 
> satsified by the
> environment. However, I believe you are standing on a pretty 
> slipperly slope. If I
> were required to show non-bypassability and tamperproofness 
> without regard to the
> environment (as suggested), I guess just about every TCSEC 
> evaluation would have a
> problem. In point of fact, I'm having trouble coming up with 
> scenarios where SEP and
> RVM can be satsified without assuming at least some measure 
> of physical protection.
> Now, if I am allowed to assume there is physical protection, 
> why can I not assume
> that an underlying abstract machine (such as hardware or even 
> an operating system) is
> used in a manner that does not allow a bypass (e.g., I don't 
> allow untrusted programs
> to run, such as in the typical firewall case). My basic 
> question now is how much of
> the SEP and RVM functions do I have to provide given my 
> assertion that they
> realistically cannot be FULLY satisified by a TOE without 
> supporting assumptions?

NIB:
> 1)  If the ST includes requirements for separation or nonbypassibility

>   (i.e., FPT_SEP or FPT_RVM), then the hardware must be included in 
>   the TOE (otherwise the TOE might be circumvented or tampered).