Revision: $Id: Security.Model.txt,v 1.1 2000/03/16 00:23:27 jmayer Exp $
Title: CCE Security Model Specification
Authors: Jonathan Mayer <jmayer@cobalt.com>

1. Overview.

	The CCE acts as a configuration "firewall" for all of the other
	components in the Qube3 architecture.  Rather than having to
	enforce security in UI, sauce, 3PD libraries, etc., all access
	control decisions are delegated to the CCE.  The CCE applies
	a simple set of rules that determines what a user can and
	can not do.
	
	The CCE Security Model uses the object as the level of granularity. For
	any given object in the system, the CCE Security Model must define who
	may perform what operations.

	Effectively, each object in the system has its own access control list
	for the various operations.

2. Objectives.

	Compact: The CCE Security Model must be represented within the
		object database in a sparse, efficient manner.
	
	Intuitive: It should be easy to understand the implications of
		setting any access permission.  This minimizes the risk
		of accidental mis-configuration.

	Groups: There must be some mechanism for creating groups of
		users who share a common access level.  This makes the
		access control system more maintainable.
		
	Operations: The fundamental operations that can be performed on
		an object are: read, write, and change permissions.  The
		fundamental operation that can be performed with a class
		is: create a new object of this class.

	Minimum Granularity: At the very least, the security system must
		be able to support different access controls for System
		Administrator, Site Administrator, and User-class users.
	
3. Object Manipulation Operations

	The Security Model consists of a set of access control lists for
	each object, which control who has the ability to perform what
	operation on the object.

3.1 Operation Definitions

	From the perspective of the security model, there are three object
	operators that must be controlled:
	
	READ is the ability to read any property of the current object.
	
	WRITE is the ability to change any property of the current object,
	other than the access control properties.
	
	CHMOD is the ability to change the access control properties.

3.2 Special Object Properties

	Every object has these properties:
	
		_READ_ALLOW
		_WRITE_ALLOW
		_CHMOD_ALLOW
	
3.3 Special Classes

	These classes of objects are handled specially:
	
		All
		User
		AbstractSite
		Group

3.4 Rules for Determining Access

	For each operation:
	
	1. Allow SysAdmin: users listed in the ADM_USER property of the
	   System object always have access.
	
	2. If a User object is listed in the ALLOW list for the operation,
	   that user is allowed to perform the operation.
	
	3. If an AbstractSite object is listed in the ALLOW list for the
	   operation, the objects within the AbstractSite's ADM_USER list
	   are considered to be part of the ALLOW list.
	
	4. If a Group object is listed in the ALLOW list for the operation,
	   the objects within the Group's MEMBERS list are considered to be
	   part of the ALLOW list.
	
	5. If an object of the special "All" list is in the ALLOW list, then
	   all users are permitted to perform the operation.

	6. If all of the above fail to enable the operation, the operation
	   is denied by default.

4.0 Class Operations

	Only the root user can install new classes, or modify existing classes.
	
	Any user is allowed to create new object instances of any class.
	
	This is safe because, if the object cannot be linked into the master
	object tree in some way, it's constructor handler will never be
	invoked by the event dispatcher.

5.0 Questions and Answers

	Q. What permissions do actuators have when they run?
	
	A. Actuators (event handlers) run as root.  If the object manipulation
	   is legal within the CCE object tree, the operation must be safe:
	   allow CCE to run as a safe way to "sudo" a task.

6.0 Conclusion.

	The last version of this document claimed:

		The CCE Security Model proves for once and for all that this is not
		going to be a trivial project.  And yet, a strong security model is
		essential for a good configuration engine.  Bite the bullet.
	
	The CCE Security Model is now significantly simpler.  It's still
	complicated in certain places, namely: that it treats different
	classes differently.  But overall this should be simple to
	configure and maintain.

Appendix A. Change log.

	$Log: Security.Model.txt,v $
	Revision 1.1  2000/03/16 00:23:27  jmayer
	Copying over the old project documentation.  Much of this still needs
	to be brought up-to-date.
	
	Revision 1.4  1999/12/24 10:18:48  jmayer
	Mucho simplification to the security model.
	
	Key change 1: got rid of _ALLOW_NEW lists.
	
	Key change 2: the "Object inherits security properties from
	another object" design requirement is rescinded.
	
	This enabled us to ditch all the _DEFERS and _DENY cruft.  Now
	it's just: _ALLOW_READ, _ALLOW_WRITE, and _ALLOW_CHMOD.
	
	Does the right thing for admins, groups, etc.
	
	Should be simpler to manage this system than the last.  Compromise
	some flexibility for transparency and simplicity.  Access for most
	objects will be a pretty straightforward analogy to the linux FS
	permissions.
	
	Revision 1.3  1999/12/02 19:43:50  thockin
	* Wed Dec 02, 1999  Tim Hockin <thockin@cobalt.com>
	- Merged CSCP spec with jonathans overview of states.
	- Added 'bogo-object' concept to spec
	- lots of FIXMEs taken care of
	- general cleanup, typos
	- updated Security Model to reflect new discussions
	- BG command allows transition from status -> read state
	- more still needed wrt permissions
	- almost done with CCE section.  merges/references from Sausalito.spec.txt
	  still needed.
	
	Revision 1.2  1999/11/19 10:28:11  jmayer
	oops, added a Log appendix.
	

	
