Confining Root Programs with Domain and Type Enforcement
Kenneth Walker et al

Goal: Limit the damage caused by subverted root programs

Overview:

* Each running process is associated with a domain

* Each object is associated with a type.  A type is an equivalence
  class for access control (Andrew' personal files, Andrew's pubilc
  files, etc.)

* Policy is expressed in a "human-friendly high-level language"
  - domains are granted permission to read, write, and execute objects
    of a given type.

  - domains are given execute permissions for different domains. This
    amounts to a more limited form of setuid.

Comments:

* DTE can be thought of as expressing an access control list between
  equivalence classes (in this case, domains for subjects and types
  for objects).  The belief is that splitting the policy problem into
  two parts (assigning objects to equivalence classes, and then
  assigning rights to these classes) is easier.  MapBox also buys into
  this philosophy.

  - as the rate of new programs increases, is it possible to generate
    new policies on the fly?

  - how general and applicable are these equivalence classes?

  - do the equivalence classes change over time?  do they change based
    on the user?

* Contrary to the authors' opinion, expressing DTE policies is not
  simple.  It is way beyond the capability of normal users.

  - DTE policies are even harder to reason about than Janus because
    they involve programs transitioning between protection domains.
    This requires reasoning about the transitive closure of all
    possible execution paths.  Yuck.

* DTE is implemented inside the operating system, which means that the
  OS implementation must be correct for this to work.  There is no
  potential for security through redundancy as in Janus.

Bottom Line: DTE makes sense in a military setting where the number of
programs and users changes slowly, and sophisticated security
expertise is available.  It's applicability outside of this realm is
in doubt.