RE: Does initial setting of rules-table need FMT_MSA.3?

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

On Wednesday, November 05, YOKOTA HIROFUMI wrote:

> 
> > When an object is created (presumably by a subject), it 
> must have security
> > attributes that are appropriate in order to uphold the 
> information flow
> > control policy. For example, in an MLS system, if the 
> subject is operating
> > at system-high, the object would presumably be created at 
> that level as
> > well.
> 
> But, the CC Part2 Annexes F.5 paragraph [792] does not say 
> so. It says:
> 
> The attributes of the information, which may be associated with the
> attributes of the container (or may not, as in the case of a 
> multi-level
> database) stay with the information as it flows.
> 

FDP_IFF.1 states: "The TSF shall enforce the [assignment: information flow
control SFP] based on the following types of subject and information
security attributes:...".
This means that the enforcement of the SFP is based on security attributes.
The absence of explicitly initialized security attributes for an object does
not necessarily mean that the TSF must transition to a degraded operation
fail-safe mode; objects have default values that are used by the TSF when
the object does not have explicitly initialized security attributes.
The information security attributes are associated with the information, and
can be but are not necessarily associated with the container of the
information. For example, a Top-Secret database might contain both
Top-Secret and Secret records. Still, all records in the database are
associated with a classification label. Records created without an explicit
classification might be considered by the TSF to be Top-Secret (restrictive)
or Unclassified (permissive).
When the information flows to and from a controlled subject, the information
classification label stays with the information as it flows. The CC doesn't
mandate that the label has to be physically attached to the information, as
long as the association holds.

> 
>  The CC distinguishes between default and initial values for security
> > attributes - default values are used when an initial value 
> is not given;
> > initial values are specified by the creator of the object. 
> In any case, it
> > should not be possible for an object to be created outside 
> of the relevant
> > policy - therefore it MUST be associated with appropriate security
> > attributes from the moment it is first created.
> 
> Yes, this is very true for an access control SFP, but an 
> information flow
> control SFP is independent from this as stated in the CC 
> Part2 Annexes F.5
> paragraph [792]: It says:
> 
> An information flow control SFP controls access to the information,
> independent of its container.
> 

The difference is as follows: in access control, the attributes considered
are attributes of the container, e.g. the database, the file, the disk, the
NIC, etc. In information flow control, the attributes are associated with
the information object. In both cases, the SFP is based on security
attributes, and those attributes must either be specified as initial values,
or deduced by the TSF from the defined default values. It is not considered
good form for an information flow control security function to display
random or unexpected behavior when faced with information for which no
initial security attributes have been specified. That's what default values
are for. They provide for predictable (hopefully desirable) behavior.

> > FMT_MSA.3 does two things:
> > 1) It specifies whether the object's security attributes default to
> > restrictive or permissive, i.e. whether the object should 
> be protected
> from
> > the first moment it is created (restrictive), or only after its
> > default-permissive security attributes are modified by an authorized
> > identified role (permissive); and
> > 2) It defines the roles that are allowed to specify initial 
> values (that
> > override the default) for an object. In a discretionary 
> access control
> > scheme, this will usually be 'the creator'. I've seen other 
> PPs/STs give
> > this as 'Nobody'. Note that you can use FMT_MSA.2 to 
> restrict what values
> > can be given to a security attribute when it is initialized 
> (as well as
> > afterwards).
> >
> > FMT_MSA.3 has a dependency on FMT_MSA.1. FMT_MSA.1 
> determines which roles
> > can modify/query/delete security attributes for EXISTING 
> objects; it also
> > determines which roles can change objects' default values.
> >
> 
> But, I think, this is meaningful for an access control SFP 
> that is firmly
> associated with subjects, objects and operations.
> 

It is also meaningful for an information flow control security function that
is firmly associated with subject, information, and operations.

> 
> > FMT_MTD.1 is used to define which roles can manage TSF data 
> that is NOT
> > security attributes. So if you have an SFR saying something 
> like: pass ALL
> > objects between 9 to 5, and NONE afterwards, changing 5 to 6 can be
> > controlled by FMT_MTD.1, because the closing time is not an 
> object or
> > subject security attribute. But if each object or subject 
> has a security
> > attribute that specifies when access is permitted, then 
> FMT_MSA is more
> > appropriate.
> >
> 
> This is the very point that I wanted to focus.
> 
> 'Time of day" could be a security attribute of a subject, 
> object and/or an
> information.
> The time value could be manipulated by FMT_MSA appropriately 
> for the default
> values, the initial setting values, and the run time 
> modification, but it is
> sure appropriate for an access control SFP.
> 
> When I mentioned the rules-table, I was attempting to explain with the
> example (you showed) in mind. "permit pass when time is less 
> than 9" and
> "deny pass when time is more than 5" are rules. The 
> restrictive/permissive
> proprieties are defined by rules, not by the values of 
> attribues. So, I
> thought, FMT_MTD might be required additionary (as a 
> dependency) for the
> information flow control SFP.
> 

We're saying the same thing. If "9 to 5" is an attribute, FMT_MSA is
appropriate. If it is not an attribute, use FMT_MTD. For example, if we are
talking about a mail filter, and each message is labeled with its validity
period, and the filter uses that label to determine whether the message is
valid, then modification of the label, e.g. an administrator extends the
validity period for a particular message to "8 to 7", that would be
restricted to appropriate roles by FMT_MSA rather than FMT_MTD. Again, in
this example, we don't usually expect the filter to explode if it encounters
a message that has no validity period label; it should either act
permissively and pass the message, or restrictively, according to the
assignment in the FMT_MSA.3 SFR.

> 
> ******************
> Finally,
> 
> The CC Part2 "2.1.3.3 Dependencies" states:
> 
> Dependencies among functional components arise when a 
> component is not self
> sufficient and relies upon the functionality of, or interaction with,
> another component for its own proper functioning.
> 
> The CC Part2 Annexes F.5 paragraph [792] states:
> 
> An information flow control SFP controls access to the information,
> independent of its container.
> .....
> The attributes of the information, which may be associated with the
> attributes of the container (or may not, as in the case of a 
> multi-level
> database) stay with the information as it flows.
> 
> The guidance I-0451 states:
> 
> Information flow control is based on some fundamental 
> characteristic of the
> information (not the container), and may not involve an 
> active subject.
> Information flow policies dictate whether information with a 
> particular
> characteristic can move from one controlled entity to another.
> ......
> More importantly, the characteristic stays with the data as 
> it moves through
> the TSF, and serves to provide the basis for the controls. 
> Subjects need not
> be involved in this flow, as might happen in a network device 
> that services
> to connect two ports.
> ******************
> 
> With those statements and the definition of the IFC/IFF, I do 
> not see why
> IFF has a dependency on FMT_MSA.

I believe you're confusing the information with its container. In a computer
system, information is modeled as objects. The object is not the container.
It is the information. The object is STORED or TRANSMITTED THROUGH a
container, such as mail storage, a database, a network; these are the
containers that might require access control.

    Nir