Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
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