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

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

Now I agree with this situation. A start-up script 'code' is not
implementing the TOE, yet merely defining attributes that are to be
configured for the TOE at start-up to support the enforcement of the TSF. I
think this form of configuration should be acceptable as long as the
administrator has a means by which to ensure such intended action is taken
(i.e. verify that the daemons excluded from the start-up script are not in
fact running).

The last paragraph of the RATIONALE section within PD 0126 states the
following:

"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. "

The last sentence clearly states that it is acceptable for administrator
guidance to require steps to enable or configure TSF-enforcing functions,
which is exactly the case for this start-up script. I would not consider the
start-up script to be implementing the TSF as and administrator could just
as easily manually invoke those daemons that are not authenticated daemons.
The start-up script merely ensures that these daemons are not executed when
the system is started. The guidance then further warns the administrator not
to execute such daemons (at least not in an unauthenticated manner) while
using the TOE. However as a sanity check, I still feel that the guidance
should also provide instructions for verifying that such unauthenticated
daemons defined are not in fact running. This way an administrator has a
means of confirming a TOE's configuration (i.e. is not running any
unauthenticated daemons) in a running state.

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 Nir Naaman
Sent: Saturday, April 08, 2006 4:11 PM
To: Multiple recipients of list
Subject: RE: PD 0126: Administrator-entered Code Used To Meet SFRs


This discussion is based on down-to-earth considerations: the ODRB has
issued a PD whose intention is to limit the extent or nature of installation
guidance. The ODRB is soliciting comments on this PD.
Some of the readers of this list believe that the stated constraints are
wrong.

In particular, these constraints might mean that some otherwise-trustworthy
products might not be able to meet customer-stated requirements because of a
Scheme-specific constraint on the competency of the administrator. In other
words, the PD suggests that while it might be reasonable to expect an
administrator to configure a hundred different integer parameters, if
somebody decides to call these parameters 'code', we can expect the
administrator to panic.

To answer your comment, I'll try to give a real-world example. Suppose a
COTS product spawns several daemons at startup, including authenticated
services (e.g. telnet, ftp) and unauthenticated services (e.g. time of day).
This says nothing about trustworthiness and/or vendor commitment, and is
perfectly fine if the ST claims FIA_UAU.1. However, now the vendor is trying
to meet a PP that requires FIA_UAU.2. The vendor chooses not to create a
different version of the product that excludes the unauthenticated services;
rather, he instructs the administrator to modify the start-up script and
comment-out the lines that spawn the unauthenticated daemons.

I think this is reasonable. It is something administrators are trained to
do.

Cheers,
    Nir


> -----Original Message-----
> From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of Olin 
> Sibert
> Sent: Saturday, April 08, 2006 6:34 PM
> 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.
> 
> 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?
> 
> Cheers -- Olin Sibert
> 
>