linux-audit: reconstruct path names from syscall events?

[Steve Grubb]

On Friday, October 07, 2011 05:38:41 PM Casey Schaufler wrote:
> On 10/7/2011 11:27 AM, Eric Paris wrote:
> > On Fri, 2011-10-07 at 10:20 -0700, Casey Schaufler wrote:
> >> On 10/7/2011 6:50 AM, Eric Paris wrote:
> >>> Casey only talked about the easy part of the reason the pathnames are
> >>> useless.  He forgot to mention
> >> 
> >> I didn't forgot to mention the whole mount point thingy.
> >> People always get hung up in coming up with ways to explain
> >> around the problem, and having already identified the root
> >> cause of the problem
> > 
> > Ok fair enough.  I guess I just saw two root problems not just one.  You
> > mentioned there existing multiple names for the same object.  I was
> > thinking of the of there not existing any name for an object which makes
> > sense at a 'system wide' level.  In any case.  We might be able to get
> > some more pathname like info, but it's never (like Casey so sagely said)
> > going to be truely useful....
> 
> The worst case is 4000 processes that opened the file under 4000
> different pathnames, all of which have since been unlinked, doing
> fchmod. At the time of fchmod there is no pathname that refers to
> the file, although 4000 pathnames are associated with the object
> whose mode is getting changed. The dev/inode pair is the only
> externally visible identifier that could possibly be used to
> name the file in the log, and as you point out, the dev is not
> reliable.
> 
> Now even with that, a path name could be useful. It just can't
> be considered definitive or unique. As for audit tracking, you
> really ought to be able to say things like "show me everything
> that happens to the file that is currently called /etc/shadow"
> and "show me everything that happens to any file called /etc/shadow",
> even though the two statements are radically different underneath.
> The problem is that 99 44/100% of the people looking at or setting
> up audit trails are going to be disinterested in or possibly
> incapable of making the distinction. Let's face it, most people
> shouldn't be using computers capable of running anything except
> AngryBirds.

I think that you missed the point of this problem report. There is a problem in path 
name resolution as has been discussed. But the problem is that we only get partial 
path information for some syscalls. The *at syscalls take 2 parameters: a previously 
opened fd and a path relative to the fd. The audit system is recording the relative 
path fine. What we don't have is what the fd points to. 

It would be unreasonable to expect a watch on /etc be added on the off chance that you 
might need 1 of those million opens to reconstruct an event. Right now we don't get 
any information about the parent directory. Neither the directory's device or inode 
gets recorded. Everything you point out is another problem.

-Steve