|
Nevertheless, auditing object
creation would not be a bad idea.
If a threat on a subject ( might be an
untrusted user) is defined in the ST and assumed to be
countered by the audit, it could be justified.
Even if such a threat is not defined
in the ST, yet, the audit could help the analysis
when mal-functions are observed regarding the relavant
operation.
So, it seems to
me, auditing object creation is useful and practical to
interprete as a CAPP
requirement.
Regards,
Hirofumi Yokota
----- Original Message -----
Sent: Sunday, February 25, 2007
12:54 AM
Subject: RE: PD 0131: Create
Object Audit Event and CAPP Compliance
I agree with Helmuth Kurth and Jim Arnold that object
creation is not necessarily required to be audited by
CAPP.
The PD notes that the C2 requirements
required the auditing of the introduction of an object into a process's
address space. Helmut Kurth retorts that there could be systems where a named
object might be created without introducing it into the user's address space.
This is certainly conceivable, and assuming anybody can create a named object
(i.e. object creation is not controlled under FDP_ACF.1) and that the object
is created with default security attributes (i.e. is not audited for
FMT_MSA.3), a 'create object' operation without a corresponding 'open
object' operation is not required to be
audited.
Named objects are those
objects which are used to share information among subjects acting on the behalf of different users, and for which access to the
object can be specified by a name or
other identity.
The PD is clearly
basing the requirement for auditing of the named object creation not on the
object in question, but is operating under the assumption that for a named
object to be created, another object must be modified to reference the newly
created object, and furthermore, that that other referencing object is covered
by the DAC policy (and therefore its
modification must be audited).
This assumption is noted in both the PD Resolution: "Object Creation is an operation that requires
an access right (because not
everyone can create everywhere)", and in the issue discussion itself:
"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)"
Strictly speaking, the only thing required to be audited in this case
is that an object was created in an identified directory, but not
which object. Still, with respect to published
PPs, PDs are considered authoritative corrections to the PP, so I read this as the point of
the PD - that the identity of the created object must also be
audited.
However, where a subject creates a named object in a global namespace
that is not access-controlled, and where the subject does not perform any
further controlled operations on that object, I don't believe this scenario is
covered by this PD, and therefore object creation in this scenario is not
required to be audited. This should be true even if the object creation
operation provided the default user data contained in the object as an atomic
operation, i.e. did not require the subject to introduce the object into the
user's address space after it was created.
Nir
I agree with Jim Arnold. The TCSEC deliberately talks about the
"introduction of objects into a user's address space (e. g. file open,
program initiation)" as the events that are required to be audited. I think
the use of this terminology was deliberate. Look also into section 5.3.2 of
the Orange Book, which states for accountability:
The third requirement is for dependable audit
capabilities. That
is, a trusted computer system must provide
authorized personnel
with the ability to audit any action that can
potentially cause
access to, generation of, or effect the release of
classified or
sensitive information. Auditing here is clearly
restricted to actions that may provide unauthorized access to information.
Whenever the creation of an object also implies that it is introduced into
the user's address space and made accessible, I agree that this event needs
to be auditable at the C2 level. However in systems where those are
different events, I think the Orange Book at C2 only required the event of
"introducing the object into the user's address space" to be audited, since
this would allow to place information into the object and therefore requires
to be controlled by the access control policy. There are systems where the
two events are clearly separated and also subject to different policies. In
some of those systems, object creation is not be restricted at all (i. e. is
not an operation covered by the DAC policy as defined in the FDPACC.1
requirement in CAPP), but access to the object is, which may result in the
situation where a newly created object is not accessible by the user that
created it. In those systems - when looking at the C2 requirements - there
is no potential access to, generation of or release of sensitive information
associated with the generation of the object and the object is also not
introduced into the creator's address space. My interpretation of the C2
requirements of the Orange Book is that in those systems the creation of
objects does not need to be audited.
Arnold, James L. Jr.
wrote:
RESOLUTION
The CAPP was the created as the CC version of the C2
requirements expressed in the Orange Book (as the LSPP
recasts B1), which requires object creation as auditable event.
I don't think the TCSEC actually identifies object creation as an
auditable event.
The CAPP covers "all operations" of controlled objects where
there need to be access rights. Object Creation is an
operation that requires an access right (because not everyone
can create everywhere). Therefore, Creation is in the set of
"all operations" and should be audited.
I don't think it is necessarily the case that object creation requires
an access right or that object creation is limited to specific users. I
can imagine many cases where objects can be freely created by subjects
and access decision are made only for subsequent attempts to open the
existing object. While there are certainly examples where object
creation is a controlled operation I don't think it is necessarily
always the case as suggested here.
RATIONALE
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.
I'm not sure about the altering TSF data statement. I suppose TSF data
somewhere would almost certainly be affected, but as indicated above, it
seems there could be cases where no security restrictions are imposed
for object creation.
It is not necessarily clear what the whole point is. The CAPP indicates
that users should be accountable for their actions. Presumably that is
limited to security related actions, perhaps meaning actions that are
otherwise restricted. Unfortunately I think audit is mistreated in
general since auditing subject actions may be distinct from auditing
user actions and, in deed, it may be hard to discern users actions from
even a long list of subject actions. I'm thinking that there may be
certain non-persistent objects where there creation isn't particularly
interesting from a security perspective and the simple creation thereof
really is not indicative of any security relevant user behavior.
--
Helmut Kurth, atsec information security
www.atsec.com
|