Towards the Design of Secure Systems

Security Policy: a finite set of rules which prohibits or grants the access to a type of objects

	objects are partitioned into disjoint set of types
	access is the way of manipulation of objects
	rules in a policy should not conflict each other

The factors affecting policy design

	the value of the object
	goal of the computation using the object
	cost of enforcing the policy

Dimensions of security policy

	object: protect what
	principal: protect from or grant to whom
	site: object residing where
	time: from when to when

Tools to implement policies

Required general properties

	small enough -> feasible to prove its properties or correctness
	fast enough
	economical: linear to actual use
	allow users to express a policy in a natural terms
	extendable so that users can create a new type of objects and specify the policy for that type

Protection mechanism assumes a capability database to query to grant a process an access to an object

Capability database: the set of all capabilities at all execution sites

Capabilities for a process defines the execution environment

Extension of capability: classical capability (defined above) + capability-based-addressing

	Every object references use capability
	Capability can be passed around

In extended capability model,

	passing capabilities can be controlled based on its contents
	capability environment of a process can change across function calls and movement of capabilities within a system

HYDRA is OS for a machine with up to 16 C.mmp processors connected to one memory

The main facility of OS for multiple processors is the protection

HYDRA skeletal backbone is an implementation of protection in terms of extended capabilities

Object has:

	a unique name of 64-bit
	a type
	representation: data part + a set of capabilities capability = a reference to another object = object name + a set of access rights auxiliary rights: type dependent rights defined by the type creator = access right to the data part kernel rights: type independent rights defined by the protection mechanism = access right to the capability part

Type object: representative object of the entire objects of the type

Types: Built-in types or user defined types

Type creation: through the CREATE access to TYPE object

Execution environment

	Execution environment is defined by an LNS (Local Name Space) object
	LNS is an ordered list of capabilities
	Each process has exactly one LNS object associated with it
	Object is referenced by the path of indices rooted in the LNS. Fig-1

In the context of extended capability, protection mechanism should be defined in terms of

	Access control enforcement
	Capability transfer operations
	Environment boundary crossing operations

Access control enforcement

	Every reference to an object is through the capability for the object
	Every reference to an object should be checked Each machine instruction is checked whether the process's LNS has appropriate capability to execute the instruction Each procedure call is checked whether the process's LNS has appropriate capability to call the procedure

Capability transfer (manipulation) operations

	DELETE ( p = search path starting from LNS, r = set of rights ) if the process is permitted to walk through path p and if KERNEL-DELETE is in rights(p), then delete the rights in r from the capability p
	MOVE ( p, c, q, d ) if the process is permitted to walk through path p and q, and if KERNEL-LOAD is in rights(p) and KERNEL-STORE is in rights(q), and if capability q does not have right d, then move the right c of capability p to d of q
	Templates Slots of capability part of an object can be initialized by templates Template is composed of: type checkrights amplifyrights If a slot is occupied by a template t, then capability c can be moved into the slot only when type of c = type of t, and rights of c includes checkrights of t also amplify the rights of c by amplifyrights of t, if KERNEL-AMPLIFY is in rights of c
	When and how is a capability moved from one object to another? HYDRA guys regarded functions as objects -> parameter passing between caller and callee Amplification of capability is only taken during parameter passing from caller to callee

Environment(= LNS) boundary crossing operations

	When a process need to work in a new environment, it does environment switch: Save the current environment into the stack Replace the current LNS with the value of the new environment Destroy the current environment and restore the old one, when the process finishes working on the new environment
	PROCEDURE type and new LNS building PROCEDURE type object has: static capabilities - required capabilities whenever the procedure is called regardless of caller's capabilities templates, which will be replaced by capabilities which caller passes as arguments CALL function: creates an empty LNS copies the static capabilities and templates into the LNS MOVE & Amplify caller's capabilities according to the rules of templates
	Note: Type and checkrights of procedure templates work as formal parameters and/or safe guard to ensure that the caller has the required capabilities to invoke the procedure

Template creation and specification of amplifyrights field should be controlled!

	Only the creator of the type(= the type object) can create the template of the type
	Creation of a new type Create the type object Define allowed access to object of the type Write procedures: code + template definition

Policy-1

	Any employee may generate memos
	Any employee having a right to access a memo may give that right to any other employee: impossible in Unix
	The author of a memo explicitly gives a memo to its recipients

Implementation-1

	TYPE: Memo
	Accesses: READ, UPDATE, ERASE
	Procedures: CreateMemo Arguments: capability of pages, initial values Return: READ, UPDATE, ERASE capability of the newly created Memo object static capability CREATE -> make any employee generate her memos no template checkrights Body write header and body to the pages passed call protection system to create an object of Memo type return capabilities of the newly created object ReadMemo template checkrights = READ for the Memo object & WRITE for the pages to which content of the memo is copied UpdateMemo template checkrights = UPDATE EraseMemo template checkrights = ERASE

Pros

Protection mechanism is fine-grained and general enough

Cons

The mechanism is overly complex. The principle of simple and clear design is ignored: Creation of new type and its accompanying functions is extremely complex. Specifying the just necessary and sufficient checkrights and amplifyrights of templates is beyond the mentality of ordinary programmer In Unix file system, there are only 3 accesses: read, write, execute. In HYDRA there can be zillions of accesses, almost all of which users have never heard about. And how does a user know which access she has on which object?

Capability axis is explained, but principal axis is not explained. uid & gid of Unix? or ACL of AFS?