Re: patch suggested by rgb for fixing auditd logs for clone syscall shows exit code as container namespace pid of child process instead of host namespace

On 2018-01-08 14:03, Steve Grubb wrote: > Hello, > > On Monday, January 8, 2018 12:49:48 PM EST madz car wrote: > > Appreciate your response on this issue. However, if you would notice the > > pid and ppid values in the same log is in the initial namespace, while the > > exit code is in a different namespace. Doesnt this make the audit log > > inconsistent? > > I would think that pid and ppid should be from the caller/parent's pov. The > exit code, on a successful call, should be the pid that the new process knows > itself by. However, that alone is not enough. pid and ppid are fields in an audit record that are reported relative to the namespace of the audit daemon that receives the message. The exit code is the pid of the process as it knows itself in the PID namespace in which it is running. Audit should not be trying to interpret it. > > How is an application supposed to analyse the logs when a single log spans > > multiple namespaces ? > > That very problem is being worked on. Richard has circulated several drafts > of how the audit subsystem will track processes through namespaces. He is > revising another draft and should circulate it again in the near future. I have a V3 ready to post. > > How does an application parsing the logs get to know if its actually a > > different pid namespace other than relying on audit to provide consistent > > information in the log? > > There needs to be a tracker ID added to audit records. The main proposal is for container IDs, but part of the proposal also outlines records to document the namespaces implicated. > > I agree it can mess up other system calls, but at least in this case for > > clone, this issue should be fixed somehow. > > I think everyone agrees on this. But the details of how it should be done are > still being pinned down. I should have been more clear that I agree it is an issue that needs to be solved, but not the way proposed. That's why clearly separating the statement of problem from the proposed solution is helpful and not getting too attached to the proposed solution as long as the eventual solution solves the problem. > > The audit logs having pid and ppids in different namespace and exit codes > > in different namespace is just making the log impossible to parse. > > I think you're trying to do something that we're currently not capable of > doing. When all stakeholders are in agreement with the specification, I am > sure that if anyone has free time to code up the specification or parts of it > so that it lands in the upstream kernel sooner than later, it would be > greatly appreciated. At first I was tempted to add a field to that record that labels that value as a "cpid" (Child PID) or something like that to make it clear that value is only valid or available for certain contexts or syscalls, but on more reflection, seems better placed in an auxilliary record to avoid it polluting the syscall record, the vast majority for whom that field won't exist.

> > Some of these connections(ssh etc) can be extremely shortlived and as such > > audit logs are the only way to track such events which is not possible > > without fixing this issue. > > Right. But the fix is much bigger. The last draft was aired here: > https://www.redhat.com/archives/linux-audit/2017-October/msg00037.html > > But a v3 draft should be out at some point. Should be very soon. Madzcar, thank you for reporting this issue and coding up and testing a solution. I'll review my V3 draft with this issue in mind. Please review it and provide feedback to the list. (Note: For kernel patches, please see the kernel patch style guide: https://www.kernel.org/doc/html/latest/process/submitting-patches.html In particular, cut/paste mangles tabs. ) > -Steve > > > Shouldnt we use one namespace in the log and as such all pid, ppids and > > exit codes should be translated to that namespace for the log ? > > > > Regards, > > Madzcar > > > > On Mon, Jan 8, 2018 at 6:23 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; 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. > > > > > > 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. > > > > > > 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. > > > > > > > -Steve > > > > > > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > > > > > index ecc23e2..9a78ecb 100644 > > > > > --- a/kernel/auditsc.c > > > > > +++ b/kernel/auditsc.c > > > > > @@ -1557,6 +1557,11 @@ void __audit_syscall_exit(int success, long > > > > > return_code) > > > > > > > > > > { > > > > > > > > > > struct task_struct *tsk = current; > > > > > struct audit_context *context; > > > > > > > > > > + > > > > > + rcu_read_lock(); > > > > > + return_code = pid_nr(find_vpid((int) return_code)); > > > > > + rcu_read_unlock(); > > > > > + > > > > > > > > > > if (success) > > > > > > > > > > success = AUDITSC_SUCCESS; > > > > > > > > > > Kindly review. > > > > > > > > > > Regards, > > > > > Madzcar > > > > > > - RGB - RGB