Re: best way to audit in vfs
On Tue, Dec 14, 2004 at 08:54:27PM +0000, Timothy R. Chavez wrote:
> - while system call is executing, additional information is
collected
> based on the data copied from userspace by the syscall. In the case of
> filesystem operation, this would be the audit attribute associated with
> the inode being worked on.
This might be a little insane, that is, from the current syscall
audit, to figure out "the inode being worked on." In ptrace there is
an audit_syscall_enter hook and audit_syscall_exit hook. In neither
hook is there a reasonable way to discover the inode associated with
the syscall argument. This is why I think its easiest to do the
logging in the VFS for this portion of the record, at least... At this
point, we have a dentry associated with an inode (the inode we're
interested in), to work with.
But the existing audit code already does this, look at audit_getname()
and audit_inode() in kernel/auditsc.c, which get called from
fs/namei.c:getname() and fs/namei.c:path_lookup() respectively.
The VFS code knows all about the inode, and the audit context is
available in the current process context.
> - when the system call is complete, the filter rules are applied
to the
> available data (including the additional info), and an audit record
> is generated and sent to userspace.
In my way, this wouldn't work to well because the syscall could be
filtered away and the VFS portion would be in userland waiting...
But that's insane from a filtering point of view ;-)
If you tell audit to only make records for operations on certain files,
you don't want syscall entry and intermediate records being sent to
userspace for all open() operations where the necessary data wasn't
available yet. I think that implies that you need to first collect data
in the kernel until you know if userspace will be interested.
Sending multiple partial audit records for every syscall to userspace and
then having auditd do all the filtering would most likely have pathetic
performance.
-Klaus