|
Date: |
1/30/2004 |
|
Subject: |
Rules governing binding should be specifiable |
|
Status |
Final |
|
CC Part #1 Reference: |
|
|
CC Part #2 Reference: |
CC Part 2, FIA_USB |
|
CC Part #3 Reference: |
|
|
CEM Reference: |
|
Issue:
The current FIA_USB component provides the ability to associate "appropriate" user security attributes with subjects. It provides no mechanism to specify any rules governing the association, and it requires that the attributes to be mapped be provided through refinement (that is, it provides no means of identifying what attributes are "appropriate").
However, in many cases it must be possible to specify how user attributes are mapped into subject attributes (e.g. for a requirement that the label assigned to a subject be within the clearance range of the user). This can not be expressed under the existing components.
Interpretation
Component FIA_USB.1 is modified to specify the attributes of users, to provide the ability to specify the rules governing the binding of user attributes to subjects, and the means to change those rules.
Specific Changes
To address this interpretation, the following changes are made to CC v2.1, Part 2:
FIA_USB.1: User-subject binding
Hierarchical To: No other components
FIA_USB.1.1: The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: [assignment: list of user security attributes].
FIA_USB.1.2: The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: [assignment: rules for the initial association of attributes].
FIA_USB.1.3: The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users: [assignment: rules for the changing of attributes].
Dependencies: FIA_ATD.1 User Attribute Definition
FIA_USB.1 User-subject binding requires the specification of any rules governing the association between user attributes and the subject attributes into which they are mapped.
The following actions could be considered for the management functions in FMT:
a) an authorised administrator can define default subject security attributes.
b) an authorised administrator can change subject security attributes.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
a) Minimal: Unsuccessful binding of user security attributes to a subject (e.g. creation of a subject).
b) Basic: Success and failure of binding of user security attributes to a subject (e.g. success or failure to create a subject).
The phrase "acting on behalf of" has proven to be a contentious issue in source criteria. It is intended that a subject is acting on behalf of the user who caused the subject to come into being or to be activated to perform a certain task.
Therefore, when a subject is created, that subject is acting on behalf of the user who initiated the creation. In cases where anonymity is used, the subject is still acting on behalf of a user, but the identity of that user is unknown. A special category of subjects are those subjects that serve multiple users (e.g. a server process). In such cases the user that created this subject is assumed to be the "owner".
Operations
Assignment:
In FIA_USB.1.1, the PP/ST author should specify a list of the user security attributes that are to be bound to subjects.
Assignment:
In FIA_USB.1.2, the PP/ST author should specify any rules that are to apply upon initial association of attributes with subjects, or "none".
Assignment:
In FIA_USB.1.3, the PP/ST author should specify any rules that are to apply when changes are made to the user security attributes associated with subjects acting on behalf of users, or "none".
Rationale
This interpretation provides the ability to specify the rules that govern attribute inheritance between users and subjects. It also makes explicit the listing of attributes to be inherited.