Re: PD 0131: Create Object Audit Event and CAPP Compliance

["Observation Decisions Review Board" <faigin@aero.org>]

The ODRB thanks all the respondents for their comments.  Two points need
to be replied to that are not appropriate to mention in the PD itself. 

1. Is the CAPP still relevant?  It is "today's" rendition of the
   Orange Book C2 requirements which were built in a "different era".
   Without igniting a whole new email firestorm;  let's just say that it
   is being used and represents a starting place for evaluating a
   product's security.  Hopefully it serves as a foundation on which to
   build more appropriate measures for today's environments. 

2. How much "accuracy" should we ascribe to words written over twenty
   years ago?  Do we take the words literally in this day and age?  Or
   do we interpret them in light of "modern" implementations? For issues
   in which the technology is directly comparable the ODRB will take the
   literal approach.  For other cases, the ODRB will attempt to apply
   the intent of the requirement against the implementation in
   question. 

As a result of this discussion, the RESOLUTION and the SUPPORT of the PD
were completely rewritten:

PD#: 0131
 
PD Title: Create Object Audit Event and CAPP Compliance

Sanitized Issue
 
Does CAPP Compliance require that object creation be an auditable event?
The CAPP is based on the TCSEC C2 requirements, and the C2 requirements
specified object creation as an auditable event. 

Note that the CAPP requires auditing of the following (excepted from the
table in the CAPP): 

FDP_ACF.1. All requests to perform an operation on an object covered by
the SFP.  

FMT_MSA.1. All modifications of the values of security attributes. 
 
FMT_MTD.1. All modifications to the values of TSF data. 
 
An argument against requiring this audit action is that the CAPP does
not list "Create Object" as an auditable event, or as an example of an
auditable event. There is also no "object" until after the object is
created and an operation is performed on the object; thus there is no
reason to audit object creation as the operation is not being performed
on an object (it does not yet exist). It is also worth noting that the
C2 requirements required the auditing of the introduction of an object
into a process's address space. It was also noted that open, read,
write, delete, close, etc. (in other words any other operation) will be
audited, so there is not a major security issue except when covert
channel related requirements are involved. There also appears to be some
past precedent where auditing the creation of an object was not required
for CAPP compliance. 
 
The argument in favor of this audit relates to the words of the CAPP. An
object being created is something covered by the Discretionary Access
Control SFP, and creation is an operation on that object. Even if one
takes the position that the formal object does not yet exist, the act of
creating of the object makes changes in security attributes and values
of TSF data, in particular the TSF data contained in the directory that
contains the newly created object (which itself is the subject of an
open and close). 

PD Resolution
 
The Controlled Access Protection Profile (CAPP) was created as the CC
version of the C2 requirements expressed in the TCSEC (as the LSPP
recasts B1). As such, auditing must meet the C2 requirements, which
means, with respect to object creation, that creation of named objects
that involve an access check must be audited. If there is no access
check involved, or if the object is a temporary or storage object only
(e.g., subject-local), auditing is not required.  

Auditing of the creation of storage objects or other objects that might
result in observable resource clashes (e.g., name clashes in a flat
namespace, storage allocation failures) would require auditing in
systems being evaluated against requirements in the TCSEC paradigm where
covert channels are of concern. 

PD Support

In general, the creation of an object alters TSF data (values or
attributes) and allocates resources, each action requiring an
appropriate access right. The CAPP, in attempting to audit "all
operations" must then include with these other audited operations, the
actual instantiation of new objects. 

The TCSEC, at the C2 digraph, requires auditing of the following events:

* Use of identification and authentication mechanisms 
* Introduction of objects into a user's address space  
* Deletion of objects from a user's address space 
* Actions taken by computer operators and system administrators and/or
  system security administrators      
* All security-relevant events
* Production of printed output 

Object creation is not explicitly mentioned in this list, although it
may fall under the general rubric of "all security-relevant
events". Note that if object creation introduces the object and makes it
accessible, then it clearly requires auditing. 

So what would make object creation a security relevant event? The
Interpretations Working Group, back in the TCSEC era, attempted to
explore this.  

I-0028 (draft) noted that "It is not necessary to independently audit
allocation of memory when it occurs as part of the creation of a subject
or object." This implied there was the potential for auditing the
creation of the object, but the memory allocation activity didn't
require independent auditing. 

I-0032 (draft) was moving toward the direction of defining Security
Relevant Events based on whether a policy-relevant decision was made. 

I-0032 (draft) took the position that it was not necessary that the
creation of objects entirely local to a single subject be an auditable
event. 

Based on these, it appears the critical aspects are (1) can the object
be shared with another subject, and (2) is there an access check
involved in the creation of the object.  

Sharing is an important factor because it is an avenue of information
flow. By auditing creation of entities that can be shared, one can
determine potential flows that go against policy. Thus, auditing of
subject-local objects (such as process-local memory scratch pads or
unnamed objects) is not necessary, as the information cannot be shared. 

There are many examples of objects that are invisible outside of a
process' address space.  Two examples are: 

1. Temporary Files -- Some operating systems provide this capability.
   Even though they are created and opened (note the distinction) in the
   "user's address space" they are invisible to all other users and
   disappear when the user's address space is deleted.   

2. Semaphores and Mailboxes -- If they are not visible to other subjects
   they might as well not exist yet they must be created and use address
   space.   There are many other objects in this category. 

They may also be described as "storage objects".  They have no real use
other than as containers for data within a process or other execution
entity. 

Access checks are important for accountability purposes. In general, DoD
guidance of the time (which the TCSEC was capturing) wanted
accountability for unauthorized access. Thus, if object creation
involved an access check and that failed, it is an action of
interest. In TCSEC terms, it is simpler to audit all creations with
access checks, noting success or failure. 

However, it is possible to conceive of some systems with flat addressing
spaces that permit any subject to create potentially sharable objects,
with no access checks performed until they are read or written. It is
difficult to categorize such creations as security relevant, although
subsequent use of the object is security relevant. It is anticipated
that this will be a rare exception. 

The justification for having an audit capability at all is to provide
user accountability. For objects of interest (shared named objects),
this includes the ability to trace the entire lifecycle: birth
(creation), education (reading and writing), and death (deletion). 

A last note: Covert channels add an interesting wrinkle to this
discussion, as creation of an object may exhaust resources (storage
channel) or create a name clash (storage channel). In such cases, if
covert channels are a concern, auditing is necessary. 

PD History

2007-02-22
    PD Created. [February 2007 ODRB Meeting Agenda Item 3.a.i]
2007-03-20
    PD rewritten to provide more substance and a better argument. [March
    2007 ODRB Meeting Agenda Item 4.d.i]