RE: FMT_MSA.3: Restrictive/Permissive Default Values

["Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.com>]

> > ******
> > FMT_MSA.3.1
> > The TSF shall enforce the [assignment: SFP] to provide [selection:
> > restrictive, permissive, other property] defaults values, 
> for security 
> > attributes that are used to enforce the SFP.
> > 
> > FMT_MSA.3.2
> > The TSF shall allow the [assignment: the authorised 
> identified roles] 
> > to specify alternative initial values to override the 
> default values 
> > when an object or information is created.
> > ******

> On the whole, I think FMT_MSA.3 is not well conceived. I 
> believe that the point of the requirement is to claim whether 
> objects are or can be protected at the time of their 
> creation. The operations were intended to allow a PP or ST 
> author to dictate or claim the protections that are provided 
> when an object is created and whether (and who) anyone can 
> act to change those automatic protections to suit their own needs.

Expanding on my last comments, I think that the distinction between default
and initial values is essentially arbitrary. At best, it seems 'default' is
a subset of potential 'initial' values. In order to be effective, the first
element of FMT_MSA.3 should be used to explain the default values (if any)
that will be applied to an object automatically by the TSF if there is no
specific direction to do otherwise. The second element of FMT_MSA.3 should
be used to explain who, if anyone, (and perhaps how) can effect a change in
the initial (including default, if they are changeable) values that will be
applied to an object when created by the TSF. 

It is possible that the TSF is not able to assign default values (i.e.,
there is no default), but rather has to receive initial values when the
object is created. It is also possible that the default value is static and
cannot be changed by anyone. Whether a user can change the default setting
to be applied indefinitely in the future or whether a user can explicitly
define alternate initial security attributes at the time of object creation
is not an important distinction, but both should be addressed in the second
element as either situation allows the user some measure of control over the
initial values whether assigned by default or not. Note that it seems that
the control of default and/or alternate initial values could be complex and
the second element of FMT_MSA.3 does not accommodate that well (e.g., some
roles may be able to control only some attributes only under some
circumstances).