PD-0131: Create Object Audit Event and CAPP Compliance

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

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).

Resolution

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.

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.

Modification 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]

References:

• Controlled Access Protection Profile, Version 1.d, National Security Agency, 8 October 1999

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0255