Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket

[Steve Grubb <sgrubb@redhat.com>]

On Wednesday, October 22, 2014 10:51:49 AM LC Bruzenak wrote:
> On 10/22/2014 10:12 AM, Eric Paris wrote:
> > On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
> >> 1) For the *at syscalls, can we get the path from the FD being passed to
> >> be
> >> able to reconstruct what is being accessed?
> > 
> > You might sometimes be able to get A path.  But every time anyone ever
> > says THE path they've already lost.  There is no THE path.  There might
> > be NO path.  Every single request with THE path is always doomed to
> > fail.
> 
> IIUC we've got to have some assurance that the path is legit for forensics.
> Technically I believe I understand and concur with what you are saying
> Eric, but as a guy on the far end of the process I know I need to be
> able to reference a complete path to a FD.
> One which we believe did exist at the time the mod occurred. To me,
> sometimes isn't really good enough. But A path probably is.
> ...

The thing is, that if an fd is open, there is an entry on 
/proc/<pid>/fd/<number> that you can use readlink on to get the path. So, if 
/proc has the info to show the outside world, why can't it be accessed from 
inside when needing it for an audit event?


> >> 9) Can we get events for a watched file even when a user's permissions do
> >> not allow full path resolution?
> > 
> > No.
> 
> No?

There are requirements that say audit should send notification on the attempted 
access in both success and failure scenarios. It doesn't say when convenient.

-Steve