Lattice-based Policies

Our framework allows incorporation of Mandatory Confidentiality [14], Mandatory Integrity [15] models and their combination. Mandatory policies govern access on the basis of classification of subjects and objects in the system. Objects and subjects are assigned security labels:

1. Confidentiality labels, e.g. Top_Secret/NASA, Sensitive/Department2
2. Integrity labels, e.g. High_integrity, Low_integrity
3. Single security labels for both confidentiality and integrity, e.g. Top_Secret/NASA, Unclassified. Assume that the first label denotes high integrity level, whereas the second one denotes low integrity level.

To prove eligibility to access an object, a subject has to present a valid credential, stating subject's security label. All access rights are divided into read-class and write-class. Appropriate rules are applied to each class. Generic conditions for read-class access rights: a) conf_read_equal:cofidentiality_label This condition specifies that a subject, wishing to get read-class access to the object has to have security clearance equal to the one, specified in the cofidentiality_label field. b) conf_read_below:cofidentiality_label This condition is used to enforce read down mandatory confidentiality rule. It specifies that a subject, wishing to get read-class access to the object has to have security clearance no less the one, specified in the cofidentiality_label field. c) integr_read_equal:integrity_label This condition specifies that a subject, wishing to get read-class access to the object has to have security clearance equal to the one, specified in the integrity_label field. d) integr_read_above:integrity_label This condition is used to enforce read up mandatory integrity rule. It specifies that a subject, wishing to get read-class access to the object has to have integrity clearance less or equal to the one, specified in the integrity_label field. Similarly we define generic conditions for write-class access rights. Assume file doc.txt has classification Sensitive/Departmen1 and integrity label Medium, then EACL for this file can be specified as:

Table 3.

Note that in the example above, everybody in the distributed system can get read or write access to the file if a valid credential stating the appropriate security label attribute is presented. This poses a requirement that security labels be unique across different security domains. This may not be easily satisfied. A possible way to restrict the scope of security labels to a particular administrative domain is to specify an additional condition such as location.