Re: best way to audit in vfs
On Tue, 2004-12-14 at 15:44, Timothy R. Chavez wrote:
Yes I've also been giving that some thought too. How we split
up
responsibility. If we do as you suggested, we'd simply have to piece
together each log message in userspace with the appropriate timestamp
and serial number to get the full record.
That is how the audit framework was designed and intended to be used,
and how it is used by SELinux presently (e.g. SELinux hook generates an
audit message, and then another one is generated at syscall exit if
we've enabled syscall auditing).
Still there would need to
be a hook there that gave the piece of the record the syscall couldn't
create, that is, the "filename=%s filterkey=%s (which could be used in
userspace to index a table that will return the full path location
that filename completes or whatever)", right?
filename (to the extent it has been copied by the kernel) is already
provided at syscall exit. You do want a hook, but it can occur very
early in the function (possibly even in a common helper like permission
that is called by everyone), and it just needs to call audit_log* with
any information not available at syscall exit, like the object identity
/ attribute, device and inode number, etc. Alternative would be to save
that state in the audit context from your hook function and extract it
in audit_log_exit() as part of the syscall exit processing, but then
youhave multi-component issues, e.g. audit may be triggered on multiple
components in a single pathname on a single syscall, so it is easier to
decompose via multiple audit_log* calls and let userspace piece it back
together based on the (timestamp,serial) tuples.
Plus the hooks to
assign "auditability" to those filenames that appear in our
watchlists. Anyway, this approach is reasonable. I'll just figure
out this route and leave it up to userspace to stich the complete
record together.
Yes. And that is the hardest part to get right, particularly in a race
free way. Look at the d_instantiate/d_splice_alias security hooks;
post_create isn't sufficient. And even the d_instantiate/d_splice_alias
hooks might not be sufficient (based on a recent bug report where an
inode is reaching inode_has_perm before it has completed inode security
initialization).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency