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

[Eric Paris]

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)