From: brian%jaguar.cs.utah.edu@cs.utah.edu (Brian Sturgill)
Subject: Re: Misinformation about os2-dos HW access (was Re: I've seen NT......
Date: 27 Aug 92 01:29:08 MDT
Organization: University of Utah CS Dept

In article <1992Aug27.053459.3853@nuscc.nus.sg> eletanjm@nuscc.nus.sg (TAN JIN MENG) writes:
>This C2 talk is getting to me.
>
>It's my impression that C2 certification applies to machine and OS
>both. Why is this necessary? Well, one example is given 2 otherwise
>identical machines/OS where one machine has a floppy drive you can boot 
>from and another machine cannot be booted off floppy. Vast difference
>in security here!
>
>All this talk about the ability to turn off/on C2 security is
>counter intuitive also (or for that matter providing a hardware on/off
>switch!). This kind of thing leaves a gaping big hole in security.
>
>I can't believe true C2 level security as discussed here is exactly very
>accurate.
>
>jin meng

Ok so here's the real scoop:

	[
	Below, excluding specific definitions of terms, etc... is the
	entire specification for C2.  I apologize if I introduced any
	errors... this was entered by hand.

	Note that below testing is not the same as certification.
	]

From:
Department of Defense Trusted Computer System Evaluation Criteria
	December 1985
	"The Orange Book"
	Page 111
	Page 116
	Pages 15-18
	Page 86

[From the glossary]

Automatic Data Processing (ADP) System
	An assembly of computer hardware, firmware, and software
	configured for the purpose of classifying, sorting,
	calculating, computing, summarizing, transmitting and
	receiving, storing, and retrieving data with a minimum of
	human intervention.
	
Trusted Computing Base (TCB)
	The totality of protection mechanisms within a computer
	system -- including hardware, firmware, and software --
	the combination of which is responsible for enforcing a
	security policy.  A TCB consists of one or more
	components that together enforce a unified security policy
	over a product or system. The ability of a TCB to
	correctly enforce a security policy depends solely on the
	mechanisms within the TCB and on the correct input by
	system administrative personnel of parameters (e.g., a
	user's clearance) related to the security policy.


2.2 CLASS(C2): CONTROLLED ACCESS PROTECTION

	Systems in this class enforce a more finely grained discretionary
	access control than (C1) systems, making users individually
	accountable for their actions through login procedures, auditing
	of security-relevant events, and resource isolation. The
	following are minimal requirements for systems assigned a
	class (C2) rating:

2.2.1 Security Policy
2.2.1.1 Discretionary Access Control

	The TCB shall define and control access between named
	users and named objects (e.g., files and programs) in the
	ADP system. The enforcement mechanism (e.g.,
	self/group/public controls, access control lists) shall
	allow users to specify and control sharing of those
	objects by named individuals, or defined groups of
	individuals, or by both, and shall provide controls to
	limit propagation of access rights. The discretionary
	access control mechanism shall, either by explicit user
	action or by default, provide that objects are protected
	from unauthorized access. These access controls shall be
	capable of include or excluding access to the granularity
	of a single user. Access permission to an object by users
	not already possessing access permission shall only be
	assigned by authorized users.

2.2.1.2 Object Reuse

	All authorizations to the information contained within a
	storage object shall be revoked prior to initial
	assignment, allocation or reallocation to a subject from
	the TCB's pool of unused storage objects. No information,
	including encrypted representations of information,
	produced by a prior subject's actions is to be available
	to any subject that obtains access to an object that has
	been released back to the system.

2.2.2 Accountability
2.2.2.1 Identifications and Authentication

	The TCB shall require users to identify themselves to it
	before beginning to perform any other actions that the
	TCB is expected to mediate. Furthermore, the TCB shall
	use a protected mechanism (e.g., passwords) to
	authenticate the user's identity. The TCB shall protect
	authentication data so that it cannot be accessed by any
	unauthorized user.  The TCB shall be able to enforce
	individual accountability by providing the capability to
	uniquely identify each individual ADP system user. The
	TCB shall also provide the capability of associating this
	identity with all auditable actions taken by that
	individual.

2.2.2.2 Audit

	The TCB shall be able to create, maintain, and protect
	from modification or unauthorized access or destruction
	an audit trail of accesses to the objects it protects.
	The audit data shall be protected by the TCB so that read
	access to it is limited to those who are authorized for
	audit data. The TCB shall be able to record the following
	types of events: use of identification and
	authentication mechanisms, introduction of objects into a
	user's address space (e.g., file open, program
	initiation), deletion of objects, actions taken by
	computer operators and system administrators and/or
	system security officers, and other security relevant
	events.  For each recorded event, the audit record shall
	identify: date and time of the event, user, type of event,
	and success or failure of the event. For
	identification/authentication events the origin of
	request (e.g., terminal ID) shall be included in the
	audit record. For events that introduce an object into a
	user's address space and for object deletion events the
	audit record shall include the name of the object. The
	ADP system administrator shall be able to selectively
	audit the actions of any one or more users based on
	individual identity.

2.2.3 Assurance
2.2.3.1 Operational Assurance
2.2.3.1.1 System Architecture

	The TCB shall maintain a domain for its own execution
	that protects it from external interference or tampering
	(e.g., by modification of its code or data structures).
	Resources controlled by the TCB may be a defined subset
	of the subjects and objects in the ADP system. The TCB
	shall isolate the resources to be protected so that they
	are subject to access control and auditing requirements.

2.2.3.1.2 System Integrity

	Hardware and/or software features shall be provided that
	can be used to periodically validate the correct
	operation of the on-site hardware and firmware elements
	of the TCB.

2.2.3.2 Life-Cycle Assurance
2.2.3.2.1 Security Testing

	The security mechanisms of the ADP system shall be tested
	and found to work as claimed in the system documentation.
	Testing shall be done to assure that there are no obvious
	ways for an unauthorized user to bypass or otherwise
	defeat the security protection mechanism of the TCB.
	Testing shall also include a search for obvious flaws
	that would allow violation of resource isolation, or that
	would permit unauthorized access to the audit or
	authentication data. (See the Security Testing
	guidelines.)

2.2.4 Documentation
2.2.4.1 Security Features User's Guide

	A single summary, chapter or manual in user documentation
	shall describe the protection mechanisms provided by the
	TCB, guidelines on their use, and how they interact with
	one another.

2.2.4.2 Trusted Facility Manual

	A manual addressed to the ADP system administrator shall
	present cautions about functions and privileges that
	should be controlled when running a secure facility. The
	procedures for examining and maintaining the audit files
	as well as the detailed audit record for each type of
	audit event shall be given.

2.2.4.3 Test Documentation

	The system developer shall provide to the evaluators a
	document that describes the test plan, test procedures
	that show how the security mechanisms where tested, and
	the security mechanisms' functional testing.

2.2.4.4 Design Documentation

	Documentation shall be available that provides a
	description of the manufacturer's philosophy of
	protection and an explanation of how this philosophy is
	translated into the TCB. If the TCB is composed of
	distinct modules, the interfaces between these modules
	shall be described.

10.1 Testing for Division C
10.1.1 Personnel
	
	The security testing team shall consist of at least two
	individuals with bachelor degrees in Computer Science or the
	equivalent. Team members shall be able to follow test
	plans prepared by the system developer and suggest
	additions, shall be familiar with the _flaw_hypothesis_
	or equivalent security testing methodology, and shall
	have assembly level programming experience. Before
	testing begins, the team members shall have functional
	knowledge of, and shall have completed the system
	developer's internals course for, the system being
	evaluated.

10.1.2 Testing

	The team shall have "hands-on" involvement in an
	independent run of the tests used by the system
	developer. The team shall independently design and
	implement at least five system-specific tests in an
	attempt to circumvent the security mechanisms of the
	system. The elapsed time devoted to testing shall be at
	least one month and need not exceed three months. There
	shall be no fewer than twenty hands-on hourse spent
	carrying out system developer-defined tests and test
	team-defined tests.


Brian