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

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

On Sunday, April 09, 2006 Tray Henefield wrote:
> 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 disagree. There is a difference between startup code that runs once as
part of the installation and generation of the TOE, before the TOE has been
declared 'operational', and code that runs every time that part of the TOE
restarts. The latter is definitely implementing the TOE. In fact, it could
be security-enforcing (e.g. if it invokes self-test scripts for FPT_TST or
FPT_AMT), and in any case it is definitely security-relevant if it is
running as root.

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

You're saying that commenting out a line in the script is O.K., but adding a
line or making a modification to a line is unreasonable, right? 
I don't understand the big difference. In any case, the administrator is
making a change to TSF 'code', and if he gets it wrong, the TSP might not be
correctly enforced.

The point I and the others are trying to make is that 'code' is not a
well-defined term; the example given is most definitely code, written in
some scripting language. To make this clear, I purposefully didn't take an
example where the daemons and command lines that must run are read out from
a configuration file, even though that too could be considered 'code', coded
in a language that is defined by the abstract machine that would be the
program parsing this configuration file.

     Nir



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