Query - System Calls Arguments in Linux Audit Kernel

[Paul Moore]

On Tue, Aug 6, 2019 at 11:35 AM Muhammad Adil Inam <20100180 at lums.edu.pk> wrote:
> As you know, linux-audit logs all the syscall arguments as a1, a2, a3, a4 as unsigned longs. In the case of some syscall, such as WRITE, the second argument, a2, stores the pointer to a buffer, where the buffer contains the content being written. I have been trying to deference the buffer from its address stored in a2. I am dereferencing the buffer currently in kernel/auditsc.c and dumping the dereferenced contents of a2 to printk. However, after building the customized kernel, auditd fails probably due to invalid pointer dereferencing.
>
>I am confused regarding the scope of that pointer variable stored in a2. I have two questions:
>
> 1) Is it possible to deference the syscall arguments in the Linux kernel, given the buffer was initially sent by the process that initiated the syscall?

In order for the syscall to work, the kernel must be able to
dereference pointers to memory passed to it from userspace.  How would
open(2) work if the kernel couldn't dereference the pathname pointer?
If you look at how the kernel implements different syscalls you will
see how that is typically done, and you will surely notice that it can
be tricky to do so safely (you can't trust the calling process to be
well behaved).

> 2) If it is possible to do so, what is the right way to go about it. What is the right file to work if the goal is to dereference the address stored in one of the SYSCALL arguments?

The answer to this depends a lot on what exactly you are trying to do.
In general I would say that the audit subsystem is probably not the
best place to unpack/dereference syscall arguments; while we do
capture information that is closely related to the syscall arguments
(e.g. we record PATH records for the open(2) syscall), we only do so
in some special cases.

My gut feeling is that you might be better off looking into some of
the kernel tracing tools, or even just something like strace/ptrace.

-- 
paul moore
www.paul-moore.com