-----Original
Message-----
From: Michelle A. Ruppel
[mailto:maruppel@saffiresys.com]
Sent: Wednesday, November 05, 2003
2:38 PM
To: Multiple recipients of list
Subject: RE: Does initial setting
of rules-table need FMT_MSA.3?
Below,
Nir Naaman said:
"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. ..."
As I have posted previously,
I am concerned about this description of the difference
between
access control and information flow control. It is easy to misinterpret.
Regardless of access control
or information flow control, the attributes of the information is usually
stored in or with the container. Therefore, it can be difficult to understand
the distinction between access control or information flow control using the
differences described above.
What is meant by "In
information flow control, the attributes are associated with the information
object."? I interpret that to mean that regardless of how the information
moves about the system, the attribute remains with the information unchanged
(unless modified by a privileged user). Am I misinterpreting?
Michelle A. Ruppel
Saffire
Systems
P.O.
Box 11154
Champaign,
IL 61826
217-359-7763
Fax: 217-359-8753
-----Original Message-----
From:
cc-cmt@nist.gov [mailto:cc-cmt@nist.gov]
On Behalf Of Nir Naaman
Sent:
Wednesday, November 05, 2003 7:11 AM
To:
Multiple recipients of list
Subject:
RE: Does initial setting of rules-table need FMT_MSA.3?
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