    
Раздел: Документация
0 ... 77 78 79 80 81 82 83 ... 117 Operations Assignment: In FDPIFC.2.1, the PP/ST author should specify a uniquely named information flow control SFP to be enforced by the TSF. In FDPIFC.2.1, the PP/ST author should specify the list of subjects and information that will be covered by the SFP. All operations that cause that information to flow to and from subjects will be covered by the SFP. As mentioned above, the list of subjects could be at various levels of detail depending on the needs of the PP/ST author. It could specify users, machines, or processes for example. Information could refer to data such as email or network protocols, or more specific objects similar to those specified under an access control policy. If the information that is specified is contained within an object that is subject to an access control policy, then both the access control policy and information flow control policy must be enforced before the specified information could flow to or from the object. F.6 Information flow control functions (FDP IFF) This family describes the rules for the specific functions that can implement the information flow control SFPs named in FDPIFC, which also specifies the scope of control of the policies. It consists of two "trees:" one addressing the common information flow control function issues, and a second addressing illicit information flows (i.e. covert channels) with respect to one or more information flow control SFPs. This division arises because the issues concerning illicit information flows are, in some sense, orthogonal to the rest of an SFP. Illicit information flows are flows in violation of policy; thus they are not a policy issue. User notes In order to implement strong protection against disclosure or modification in the face of untrusted software, controls on information flow are required. Access controls alone are not sufficient because they only control access to containers, allowing the information they contain to flow, without controls, throughout a system. In this family, the phrase "types of illicit information flows" is used. This phrase may be used to refer to the categorisation of flows as "Storage Channels" or "Timing Channels", or it can refer to improved categorisations reflective of the needs of a PP/ST author. The flexibility of these components allows the definition of a privilege policy within FDPIFF.1 and FDPIFF.2 to allow the controlled bypass of all or part of a particular SFP. If there is a need for a predefined approach to SFP bypass, the PP/ST author should consider incorporating a privilege policy. FDP IFF.1 Simple security attributes User application notes This component requires security attributes on information, and on subjects that cause that information to flow and subjects that act as recipients of that information. The attributes of the containers of the information should also be considered if it is desired that they should play a part in information flow control decisions or if they are covered by an access control policy. This component specifies the key rules that are enforced, and describes how security attributes are derived. For example, this component should be used when at least one of the information flow control SFPs in the TSP is based on labels as defined in the Bell and LaPadula security policy model [B&L], but these security attributes do not form a hierarchy. This component does not specify the details of how a security attribute is assigned (i.e. user versus process). Flexibility in policy is provided by having assignments that allow specification of additional policy and function requirements, as necessary. This component also provides requirements for the information flow control functions to be able to explicitly authorise and deny an information flow based upon security attributes. This could be used to implement a privilege policy that covers exceptions to the basic policy defined in this component. Operations Assignment: In FDPIFF.1.1, the PP/ST author should specify the information flow control SFPs enforced by the TSF. The name of the information flow control SFP, and the scope of control for that policy are defined in components from FDPIFC. In FDPIFF.1.1 the PP/ST author should specify the minimum number and type of security attributes that the function will use in the specification of the rules. For example, such attributes may be things such as subject identifier, subject sensitivity level, subject clearance level, information sensitivity level, etc. The minimum number of each type of security attribute should be sufficient to support the environmental needs. In FDPIFF.1.2 the PP/ST author should specify for each operation, the security attribute-based relationship that must hold between subject and information security attributes that the TSF will enforce. In FDPIFF.1.3 the PP/ST author should specify any additional information flow control SFP rules that the TSF is to enforce. If there are no additional rules then the PP/ST author should specify "none". In FDPIFF.1.4 the PP/ST author should specify any additional SFP capabilities that the TSF is to provide. If there are no additional capabilities then the PP/ST author should specify "none". In FDPIFF.1.5, the PP/ST author should specify the rules, based on security attributes, that explicitly authorise information flows. These rules are in addition to those specified in the preceding elements. They are included in FDPIFF.1.5 as they are intended to contain exceptions to the rules in the preceding elements. An example of rules to explicitly authorise information flows is based on a privilege vector associated with a subject that always grants the subject the ability to cause an information flow for information that is covered by the SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify "none". In FDPIFF.1.6, the PP/ST author should specify the rules, based on security attributes, that explicitly deny information flows. These rules are in addition to those specified in the preceding elements. They are included in FDPIFF.1.6 as they are intended to contain exceptions to the rules in the preceding elements. An example of rules to explicitly authorise information flows is based on a privilege vector associated with a subject that always denies the subject the ability to cause an information flow for information that is covered by the SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify "none". 0 ... 77 78 79 80 81 82 83 ... 117 |
