On Mon, Jan 8, 2018 at 7:53 AM, Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 2018-01-05 13:07, Steve Grubb wrote:
> On Friday, January 5, 2018 6:00:01 AM EST madz car wrote:
> > Hi Guys,
> >
> > Please refer to the issue details at github :
> >
https://github.com/linux-audit/audit-kernel/issues/68
> >
> > Here is a patch as suggested by rgb, i can confirm that it works.
>
> By hooking this function, doesn't this change the return code for all
> syscalls?
Yes, you are right, Steve. This would give bogus return values for all
other syscalls.
Yes, this patch is not something we want to merge.
Madzcar, I assume you can confirm that this patch will give
incorrect
results for all other syscalls for the "exit" field.
So, that should be in kernel/fork.c:_do_fork(), or rather, just replace
the pid_vnr() call with pid_nr(). However, this will mess up all
callers (clone(2), fork(2), vfork(2) kernel_thread(), do_fork()), who
expect the return value in the caller's PID namespace, so that won't
work. The return value is technically correct for the PID namespace
from which it was called and reported correctly in the audit record.
I think we should just leave the current behavior intact for the time
being; the information being reported is correct, even if it is a bit
confusing outside of the initial PID namespace. Yes, I understand it
may be a bit awkward, but there are plenty of things that are
currently awkward when audit is used with the various
namespaces/containers. The good news is that we are currently working
on trying to solve these issues; it make take some time to get
everything sorted, but solving this as part of the larger, multi-step
effort makes much more sense than a quick and dirty hack now.
Madzcar, the way you are trying to interpret the results from the
audit
record is clever, but not going to work without another way to translate
that value lifted out of the audit record.
I don't know if there is a userspace tool or call to translate PIDs
between namespaces.
--
paul moore
www.paul-moore.com