best way to audit in vfs

Serge E. Hallyn serue at us.ibm.com
Tue Dec 14 20:50:14 UTC 2004


Tim,

Why can't you store the info in the current->audit record until syscall
exit, and only send a message to userspace if the syscall exit says to
do so?

-serge

Quoting Timothy R. Chavez (chavezt at gmail.com):
> Stephen,
> 
> 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.  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?  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.
> 
> (send this privately by accident)
> 
> On Tue, 14 Dec 2004 15:03:08 -0500, Stephen Smalley <sds at epoch.ncsc.mil> wrote:
> > On Tue, 2004-12-14 at 15:00, Timothy R. Chavez wrote:
> > > Hello,
> > >
> > > I've been kind of thinking about this.  Presumably, we want to audit
> > > both failed and successful attempts in whatever vfs function we happen
> > > to be in.  For instance, if we fall out of vfs_mkdir because
> > > may_create returned an error, we'd like to receive an audit message
> > > that said something like, "filename=myfile syscall= mkdir()
> > > error=<errno>.....", but, would I want to do this by hooking each
> > > conditional statement?  Is there a better approach?  The only other
> > > one I can think of would be to have one exit point in the functions
> > > and audit right before we exit...
> > 
> > The audit framework already lets you audit on syscall exit, which lets
> > you capture information like this.  As I understand it, you don't need
> > additional hooks for that purpose, just for enabling auditing based on
> > object identity and for propagating audit attributes on objects.
> > 
> > --
> > Stephen Smalley <sds at epoch.ncsc.mil>
> > National Security Agency
> > 
> > 
> 
> 
> -- 
> - Timothy R. Chavez
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
> 




More information about the Linux-audit mailing list