[PATCH] audit: audit on the future execution of a binary.

[Steve Grubb]

On Wednesday, July 03, 2013 10:48:56 PM Richard Guy Briggs wrote:
> I've gone back over the discussion of this feature and some of the
> background in the past couple of years on this list...
> 
> We've got a kernel deadline coming up in the next month if we want to
> get something included in RHEL7 if you have the interest and time to
> evolve this patch (the userspace patch can follow...).
> 
> As has been discussed, passing in an inode reference is incomplete,
> since it would need to be qualified by a device reference at minimum.
> And even then, it isn't atomic and could change by the time the kernel
> even sees this rule request.
> 
> So, the next step is to convert the path to a device/inode in the kernel. 
> If this is done at the time of registering the filter rule, if/when the
> rule is invalidated then the rule would be dropped, logged.  It also means
> that anything else also hardlinked to it would be acted upon.
> 
> Going one step further, if instead we can arrange an fsnotify() hook on
> rule registration, we could act on that path when it is executed,
> renamed, unlinked (and destroyed if the refcount goes to zero), etc.
> 
> So, it should be passed as a path, logging the rule addition with path
> only at first.  When the rule is triggered then log the requested path,
> effective path, device/inode along with the user context.
> 
> The user, carefully crafting other rules can give other information.

This sounds like how I would expect it to be. You pass a path and the kernel 
converts is very much like filesystem watches to device/inode. But the next 
step is when the execve syscall matches with the path, then the rule is 
further converted to have the pid instead of the inode/device. This is 
basically following the established pattern we already have for watching files.

 
> A watch on the containing directory (/usr/bin) could help in case that
> executable pathname disappears and re-appears since the containing
> directory is less likely to go away, but it will be noisy.

Not sure this is necessary. If this is done for file system watches, then its 
an established pattern and we should continue to follow it.

-Steve