RE: PD 0126: Administrator-entered Code Used To Meet SFRs

["Trey Henefield" <trey@cceval.com>]

I would just like to indicate that in the initial email that started this
discussion, the first example that was pointed out was a case in which an
administrator must type in part of the TOE representation (e.g., source
code, script,
procedure). By this wording, it sounded as if it was pertaining to code in
which implements the TSF enforcement as opposed to code that configures
parameters required to support the TSF enforcement.

In the example explained below, an ACL rule would simply define what set of
security attributes are to be accepted/denied by an access control module.
In such case, PD 0126 allows an administrator to define the code for
configuring the ACL rules but would not allow an administrator to define the
code which implements the access control module.

The last paragraph within the RATIONALE section of PD 0126 does make this
clear:

"The developer must deliver as part of the TOE code or executable (either
with the delivered package or via an approved patch or update mechanism) all
TSF- enforcing or supporting functions required.  It is acceptable for
administrator guidance to require steps to enable or configure TSF-enforcing
or supporting functions, but not implement them when they are absent from
the TOE."

Kind regards,


Trey Henefield
Principal
CC Eval Prep
http://www.cceval.com
(512) 350-2749

-----Original Message-----
From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of Arnold, James L.
Jr.
Sent: Monday, April 10, 2006 8:34 AM
To: Multiple recipients of list
Subject: RE: PD 0126: Administrator-entered Code Used To Meet SFRs



> Although a lot of words have passed by lately on this topic, and I 
> can't honestly say I've read them all in detail, it seems that the 
> discussion is focusing on how many angels can dance on a paragraph of 
> the CC.  No one here seems to be defending the approach of having the 
> administrator type in TSF code as being a sensible or sound approach.

Evaluations are based on rules and my arguments are against a position that
limits potential solutions (that evidently has no basis in any
requirements) rather than being for the specific solution. From my
perspective, the notion of entering 'code' is irrelevant. Just what is code
anyhow and what makes it more special than critical configuration data
(e.g., configurable rules)? Rather, I think the issue is just about guidance
(to configure the TOE).

Note that this discussion has identified a number of confusions about CC
concepts that I think are fairly clear. The difference between 'delivery'
and 'installation, generation, and start-up' is one. The notions of
implementing and creating the TSF are others. 

While perhaps having an administrator enter code is not ideal, it doesn't
necessarily result in a less secure solution than would other types of
guidance. I think the distinction is all but arbitrary and the issue truly
is (or should be) about the potential for misuse. The PD issue statement
indicates 'enter code to enforce the SFR' - just what does that mean? Are
statements interpreted by the rest of the TSF code?
Is an ACL or firewall rule 'code'? I think the CC has it right, though it is
subjective, that the evaluation needs to assess (and limit where
necessary) misuse potential.

> Is that indeed the consensus, or would someone like to step up and 
> explain why this approach is such a great idea, what benefits it 
> provides for the product customer, and, perhaps, why it should be 
> taken as evidence that the developer has a clear understanding of how 
> to create trustworthy products and has a meaningful commitment to 
> delivering them?

I think no one has suggested the approach is a great idea. I expect that
someone could present examples where the circumstances for entering security
attributes and other TSF data are also not great ideas, but that doesn't
mean they can or should be rejected a priori. As for potential benefit, I
suppose that if the code created by the developer, evaluated by the
evaluation team, and configured an administrator (provided the instructions
were somehow reasonable), the user may end up with an additional security
feature that otherwise likely would have been excluded from the evaluation.
So, is it better to offer the user such a feature (that they have to
configure by typing in something like
code) or not?