Re: [PATCH] Add audit uid to netlink credentials
On Thu, Feb 10, 2005 at 10:10:23AM -0800, Casey Schaufler wrote:
--- Klaus Weidner <klaus(a)atsec.com> wrote:
> Both CAPP and LSPP assume trustworthy administrators, and those
> protection profiles don't really support the concept of fine grained
> capabilities for not-quite-administrator tasks.
I don't know where you get that idea, as it is inconsistent with the
evaluations I have done. A fine grained capability model that is used
will always make an evaluation easier. A process that runs with partial
privilege requires much less supporting evidence for evaluation than
one that has superuser privilege. The Criteria may not require fine
grained privilege, but that does not mean it doesn't help.
My point was that the security functional requirements in CAPP and LSPP
related to audit and user management only differentiate between
authorized users and authorized administrators, and adding a finer
grained distinction to those SFRs would be incompatible with CAPP/LSPP.
CAPP and LSPP permit extending the DAC and MAC policies by adding
additional rules such as capability-based ones, but I'd normally expect
that to cause more work instead of less when evaluating since all claims
related to that policy would then need to be sufficiently tested and
verified. But I think that's getting off-topic for this list.
> The CAPP and LSPP audit requirements include that audit records
> contain the subject identity, this corresponds to the login UID.
The subject identity is the name of the subject, that is the process
ID. The user associated with the session is the login UID. The user is
not the subject.
Sorry, I blame lack of caffeine for that mixup. The requirement I meant
was that each auditable event needs to be associated with the identity of
the user that caused the event. In the context of this discussion, that
means that the login UID in audit records needs to correspond to the user
identity of the user on whose behalf the process (subject) runs.
For cron/at and other indirect execution methods, the daemon running the
jobs needs to be able to correctly associate the login UID of the user
who submitted the job with the audit records generated by that job.
Usually such daemons will need the capability to change the login UID for
forked processes in addition to generating user messages with a specific
login UID included in the record, so the distinction between those two
capabilities isn't all that useful in this case.
It is actually a very good idea to maintain modifications to system
security databases outside the audit trail proper. In the Orange Book
days the NSA went so far as to declare a that a reasonable procedure
for keeping them under revision control would be sufficient to meet the
audit requirements.
Hmmm, this doesn't match the application note for FAU_SAR.1 in CAPP and
LSPP that mentions that it is expected that a single tool will exist that
satisfies all the various requirements related to audit information
access. Of course application notes aren't normative, and you could claim
that "grep" is the single tool usable for all types of audit trail
access...
-Klaus