Hydra

   * Hydra: an OS kernel for multiprocessing environments which provides
     fine-grained protection.
   * Philosophy
        o ``Universal applicability'', ``absolute reliability'': the goals
          at the heart of Hydra's facilities.
        o Minimalism: Hydra is a kernel, not an entire OS.
        o Multiprocessing support: an important goal. Conservative to ensure
          that Hydra will work, but flexible enough to make experimental
          research easy.
        o Separation of mechanism and policy.
        o Design and implementation methodology coupled. (?)
        o Not restricted to hierarchy: more flexible structure allowed,
          supported, encouraged.
        o Protection considered important: universal, uniform, fine-grained.
          Implemented with capabilities.
        o High software reliability.
        o Emphasis on resources. I simply must quote the following excellent
          definition of an OS:

          If a kernel is to provide facilities for building an operating
          system and we wish to know what these facilities should be, then
          it is relevant to ask what an operating system is or does. Two
          views are commonly held: (1) an operating system defines an
          ``abstract machine'' by providing facilities, or resources, which
          are more convenient than those provided by the ``bare'' hardware;
          and (2) an operating system allocates (hardware) resources in such
          a way as to most effectively utilize them. Of course these views
          are, respectively, the bird's-eye and the worm's eye views of what
          is a single entity with multiple goals. Nevertheless, the
          important observation for our purposes is the emphasis, placed in
          both views, on the central role of resources -- both physical and
          abstract.
        o Strict typing, abstractions, objects. Examples: procedure,
          process, LNS.
   * Protection mechanism
        o Protection is a mechanism; security is a policy. Hydra protection
          facilities should provide a flexible mechanism which enable
          implementation of high-security systems, if configured correctly.
        o Reject strictly hierarchical models. Reject ``owner-based''
          models.
        o Fine-grained: the object is the unit of protection.
        o Capability: object reference + access rights on that object.
          Access rights determine the list of operations that may be
          performed on that object. (Access rights divided into two sets:
          kernel rights are type-independent, and auxiliary rights are
          type-dependent.) Unforgeable, since all access to a capability
          must go through the kernel.
        o Each object may include a list of capabilities referencing other
          objects in it. (Picture a directed graph: objects are nodes in the
          graph and capabilities are links.) For any capability c
          referencing an object o containing a list of capabilities
          c1,c2,..., applications with access to c can get access to c1 only
          if a special kernel right , ``walk'', is granted to the
          application by c; this allows path names. (In the directed graph,
          you get access to the closure of all objects reachable along a
          path such that every capability in the path [except possibly the
          last] grant the ``walk'' right.)
        o LNS (``local name space''): kinda like a cross between a stack
          frame and a generalized address space. Execution environment has a
          LNS object associated with it; LNS objects change upon procedure
          call, as described below. LNS is implemented as a list of
          capabilities which may be accessed by the program at that time.
        o Procedures: procedure are objects, but they have special behavior
          with regard to capabilities. The callee's rights can be a subset,
          a superset, or disjoint from the callee's rights. This is
          implemented with a ``check-rights'' field in the procedure
          capability: a caller must already have those rights. There is also
          a ``regular rights'' field which increases the callee's rights
          over that of the caller. Both fields are in the ``template'', a
          field in the procedure capability. That the callee can have more
          rights than the caller, but the caller can't get direct access to
          those extra rights.
        o The kernel is invoked on every procedure call to change the LNS.
          The kernel is also invoked on every access to capability. Eek!
        o Subsystems are created through the type interface. You can create
          a new type, and you can instantiate new objects of a given type.
          Both are operations on objects, and thus capabilities are used to
          control such operations.
        o An example: bibliography system with access control. Protection of
          the bibliography system's internals, of access to the bibliography
          database. Fine-grained controls on
          read-record,update-record,delete,read-annotations, access to
          program; security policy differentiates between database owner,
          accesor, and system implementor.
        o Summary: very flexible, fine-grained protection. Looks
          performance-intensive though.