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

On Wed, 2014-10-22 at 10:51 -0500, 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. > ... >From the PoV of the process in question there was, at some point, A path. That I agree with. But imagine I clone a new mount namespace and don't share my changes with the parent namespace. Now I mount something new in that child namespace. What is A path for a file in the new mount? From the parent namespace there is NO path, ABSOLUTELY NO PATH. (guess which mount namespace auditd lives in, by the way). From the PoV of the processes in the child mount namespace there is A path, but it's possibly/probably completely meaningless to the admin. /etc/shadow != /etc/shadow the admin cares about... readlink() doesn't work in this case either. Sometimes there just plain is no path. So yeah, I'm betting MOST of the time we can come up with A path, but that's not exactly what you want either :-(

>>> 9) Can we get events for a watched file even when a user's permissions do not >>> allow full path resolution? >> No. > No? Say I set a watch for failure to open /path/to/my/file. If someone comes along and says open(/path/to/my/file) but they do not have execute permissions on /path/to/ their request will be denied. Not because they didn't have permission to open /path/to/my/file, but because they didn't have permission to open /path/to. Watches do not, and can not, emit a rule for that. The rule you requested (failure to open /path/to/my/file) was not violated. The kernel did not try to open /path/to/my/file. It tried to open /path/to/ and died right there. If you care about things being unable to open /path/to/, put a watch on /path/to (although I'm not 100% such watches actually work, but at least the theory is right and maybe that could be fixed)