Type enforcement

The concept of type enforcement (TE) in the field of information technology is related to access control. Implementing TE, gives priority to “mandatory access control” (MAC) over “discretionary access control” (DAC). Access clearance is first given to a subject (e.g. process) accessing objects (e.g. files, records, messages) based on rules defined in an attached security context. A security context in a domain is defined by a domain security policy. In Linux security module (LSM) as SELinux, the security context is an extended attribute. Type enforcement implementation is a prerequisite for MAC, and a first step before “Multi-Level Security” (MLS) or its ersatz “Multi categories Security” (MCS). It is a complement of “role based access control” (RBAC).

Control

Type enforcement implies fine grained control over the operating system, not only to have control over processes execution, but also on “domain transition” or authorization scheme. This is why it is best implemented as a kernel module, as is the case with SELinux. Using Type Enforcement is a way to implement the FLASK architecture.

Access

Using type enforcement, users may (as in Microsoft Active Directory) or may not (as in SELinux) be associated to a domain, although original type enforcement model implies so. It is always necessary to define a TE access matrix containing rules about clearance granted to given security context, or subjects rights over objects according to an authorization scheme.

ecurity

Practically, type enforcement, evaluate a set of rules from the source security context of a subject, against a set of rules from the target security context of the object. A clearance decision occurs depending on the TE access description (matrix…). Then, DAC or others access control (MLS / MCS, …) apply.

History

Type enforcement was introduced in the Secure Ada Target architecture in the late 1980s. A full implementation was developed in the [http://www.cryptosmith.com/archives/179 LOCK] system. The Sidewinder Internet Firewall was implemented on a custom version of Unix that incorporated type enforcement.

A variant called "domain type enforcement" was developed in the Trusted MACH system.

The original type enforcement model stated that labels should be attached to subject and object: a “domain label” for a subject and a “type label ” for an object. This implementation mechanism was improved by the FLASK architecture, substituting complex structures and implicit relationship. Also, the original TE access matrix was extended to others structures: lattice-based, history-based, environment-based, policy logic… This is a matter of implementation of TE by the various operating systems. In SELinux, TE implementation does not internally distinguish TE-domain from TE-types. It should be considered a weakness of TE original model to specify detailed implementation aspects such as labels and matrix, especially using the terms “domain” and “types” which have others, more generic, wide acceptance.

References

* P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. " [http://www.jya.com/paperF1.htm The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments] ". In Proceedings of the 21st National Information Systems Security Conference, pages 303–314, October 1998. [http://csrc.nist.gov/nissc/1998/proceedings/paperF1.pdf]
* [http://www.cryptosmith.com/archives/179 LOCK - A trusted computing system]