Re: linux-audit: reconstruct path names from syscall events?

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.