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

[Steve Grubb]

On Wednesday, October 22, 2014 02:18:00 PM Eric Paris wrote:
> 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. 

All of these are privileged ops. Meaning you would have to be tracking the 
actions of an admin who could do all kinds of bad things to a system.

> What is A path for a file in the new mount?

Does openat allow an fd in one name space and a file name in another?

> From the parent namespace there is NO path, ABSOLUTELY NO
> PATH.

Without getting into trick situations like this, how about we get it for the 
normal run-in-the-mill-nothing-tricky-going-on-here system? Even that would be 
immensely helpful. Especially since glibc has switched over to openat and 
newer platforms like aarch64 don't have open(2).


> (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)

If I have this rule

-a always,exit -S openat -F exit=-EPERM

The path is sitting in arg2. It not lost or inaccessible. We can't see it in 
current audit records because we get a pointer to the string as arg2. I would 
think if path resolution couldn't happen, we could get a substitute record 
that identifies the string passed as arg2.

-Steve