[Top] [All Lists]

Re: [PATCH] Add audit uid to netlink credentials

To: Linux Audit Discussion <linux-audit@xxxxxxxxxx>
Subject: Re: [PATCH] Add audit uid to netlink credentials
From: Klaus Weidner <klaus@xxxxxxxxx>
Date: Thu, 10 Feb 2005 11:52:21 -0600
Cc: kuznet@xxxxxxxxxxxxx, davem@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <1108047396.19262.537.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <36282A1733C57546BE392885C06185927377BE@xxxxxxxxxxxxxxxxxxxxx> <1108047396.19262.537.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Thu, Feb 10, 2005 at 02:56:36PM +0000, David Woodhouse wrote:
> On Thu, 2005-02-10 at 09:37 -0500, Chad Hanson wrote:
> > In your example of a process watching daemon, why would this daemon want to
> > spoof the credentials of the watched process? I can think of two examples.
> Perhaps I misunderstand the intent of userspace AUDIT_WRITE. Can you
> provide examples of why you _wouldn't_ want to let a dæmon which is
> already sending random unvetted AUDIT_WRITE messages also specify the
> loginuid on _those_ messages?

A few comments on this issue from the point of view of common criteria
evaluations... Briefly, either choice of implementation would be okay.

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.

The CAPP and LSPP audit requirements include that audit records contain
the subject identity, this corresponds to the login UID. The point of the
user messages is to support proper auditing of actions that aren't
directly related to system calls, such as authenticating users, modifying
security databases, and similar things. This is always done by trusted
processes, so the technical method used to get the login UID into the
audit record for user messages doesn't matter as long as it can't be
falsified by non-administrators.

A CAPP/LSPP compliant implementation could for example completely bypass
the kernel and append user messages from trusted processes directly to
the audit log file - I'm not saying that would be a good idea, but it
could be compliant.


<Prev in Thread] Current Thread [Next in Thread>