|
Let me correct my previous
message.
I was saying "nice to have" interpretation. It
was wrong.
In the seriousness of handling the CAPP
interpretation, I agree that we must interprete the CAPP along with
the exact wording and your past practice.
Regards,
Hirofumi
Yokota.
----- Original Message -----
Sent: Monday, February 26, 2007
4:58 PM
Subject: Re: PD 0131: Create
Object Audit Event and CAPP Compliance
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
|