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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
