Alternative Forms

• Information Flow Model

Definitions

Definition 1

A policy that prescribes how information is authorized to flow between subsystems in a system.

Related Terms

Quotes

Information flow policies are concerned with the flow of information from one security class to another. In a system, information actually flows from one object to another. The models I discuss treat “object” as an undefined primitive concept. An object can be informally defined as a container of information. Typical examples of objects are files and directories in an operating system, and relations and tuples in a database.

An information flow model FM is defined by

Fm = ⟨ N, P, SC, ⊕, ⭢ ⟩.

N = { a, b , . . . } is a set of logical storage objects or information receptacles. Elements of N may be files, segments, or even program variables, depending on the level of detail under consideration. Each user of the system may also be regarded as an object. P = { p, q, ... } is a set of processes. Processes are the active agents responsible for all information flow.

SC = { A, B, ... } is a set of security classes corresponding to disjoint classes of information. They are intended to encompass, but are not limited to, the familiar concepts of "security classifications," "security categories," and "need to know" [9, 23]. Each object a is bound to a security class, denoted by a, which specifies the security class associated with the information stored in a. There are two methods of binding objects to security classes: static binding, where the security class of an object is constant, and dynamic binding, where the security class of an object varies with its contents. Users may be bound, usually statically, to security classes referred to as "security clearances" [2, 22, 23]. Each process p may also be bound to a security class, which we denote by p. In this case, p may be determined by the security clearance of the user owning p or by the history of security classes to which p has had access.

The class-combining operator "⊕" is an associative and commutative binary operator that specifies, for any pair of operand classes, the class in which the result of any binary function on values from the operand classes belongs. The class of the result of any binary function on objects a and b is thus a ⊕ b. By extension, the class of the value of an n-ary function f(a₁, ... ,aₙ) is a₁ ⊕ ... ⊕ aₙ. To avoid semantic ambiguities that may arise when two different functions over the same domain have overlapping ranges, we assume that the operator "⊕" is independent of the function used to combine values. No generality is lost by this assumption since the effect of a function-dependent "⊕" can be simulated by an appropriate set of processes using a function-independent "⊕" [4]. The set of security classes is closed under "⊕".

A flow relation "⭢” is defined on pairs of security classes. For classes A and B, we write A ⭢ B if and only if information in class A is permitted to flow into class B. Information is said to flow from class A to class B whenever information associated with A affects the value of information associated with B. In this paper we shall be concerned only with flows which result from (sequences of) operations that cause information to be transferred from one object to another (e.g. copying, assignment, i/o, parameter passing, and message sending). This includes flows along "legitimate" and "storage" channels. We shall not be concerned with flows along "covert" channels (i.e. a process's effect on the system load) [16].

The security requirements of the model are simply stated: a flow model FM is secure if and only if execution of a sequence of operations cannot give rise to a flow that violates the relation "⭢". If a value f(a₁, ... ,aₙ) flows to an object b that is statically bound to a security class b, then a₁ ⊕ ... ⊕ aₙ ⭢ b must hold. If f(a₁, ... ,aₙ) flows to a dynamically bound object b, then the class of b must be updated (if necessary) so that a₁ ⊕ ... ⊕ aₙ ⭢ b holds for this case also. Assuming that "⭢" is transitive, it is easily shown that the security of individual operations implies that of arbitrary sequences of operations [4]. The assumption of transitivity is justified below.

Bibliography

• Denning, 1976

• Sandhu, 1993

See Also