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

[Nir Naaman <nir.naaman@metasec.com>]

Title:

Magosányi Árpád wrote:
> There are a lot of tools which use a full-grown programming
> language as its configuration interface, and some of them
> does not hide this fact, thus making things plain and simple.
> I do not thing that these tools should be discriminated.

Let's define a programming language with the following operators. I will leave semantics to the imagination of the reader:
Allow(<source>, <destination>, <service>)
Block(<source>, <destination>, <service>)
Log(<source>, <destination>, <service)

Operators can be combined. When more than one operator is defined in the program, they are executed sequentially in the order defined.

I could add conditional and loop statements, but I think that would only confuse the discussion.

This a specialized firewall programming language. It is applied by the underlying abstract machine to IP packet streams that are abstracted into service requests. If no operator has been applied to a packet, or the Allow operator is used, the packet can flow through to its presumed destination.

 

Obviously, when we start with an empty program, the access control module has not been implemented. No access control is applied. Packets flow through freely. All enforcement code is absent from the TOE.

 

What PD 0126 is saying that the vendor cannot supply guidance that tells the administrator:

"The administrator must enter the following as the last operator in any program: 'Block(ANY, ANY, ANY)'."

 

The vendor must supply all operators ready-made in the correct sequence, and the administrator is allowed to enable or disable coded rules but not to author them if they are absent from the TOE.

 

I presume most of the readers of this list would not agree with the above statement. So what is this discussion about? Is it O.K. for these rules to be selected from a drop-down menu or some other GUI construct, but typing them in using some kind of text editing tool is beyond reasonable administrator competence?

 

Olin Sibert might claim that this example shows an absence of "a clear understanding of how to create trustworthy products and [has] a meaningful commitment to delivering them". That the block-any rule should be hard-coded by the developer, rather than being left to the discretion of the administrator. I contend that on the contrary, in the world of COTS, products are often being used fruitfully exactly because they provide such flexibility. In this example, the product might have originally been produced as an IDS/IPS tool, and therefore implemented permissive defaults.

 

    Nir

> -----Original Message-----
> From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of
> Trey Henefield
> Sent: Tuesday, April 11, 2006 5:19 AM
> To: Multiple recipients of list
> Subject: RE: PD 0126: Administrator-entered Code Used To Meet SFRs
>
>
> 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?
>
>
>
>
>
>