From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: Query - System Calls Arguments in Linux Audit Kernel Date: Wed, 7 Aug 2019 10:44:45 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx14.extmail.prod.ext.phx2.redhat.com [10.5.110.43]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B80EC67C96 for ; Wed, 7 Aug 2019 14:45:01 +0000 (UTC) Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 369C1309265B for ; Wed, 7 Aug 2019 14:44:58 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id h10so14271378ljg.0 for ; Wed, 07 Aug 2019 07:44:58 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Muhammad Adil Inam <20100180@lums.edu.pk> Cc: "linux-audit@redhat.com" , Ali Ahad <20100284@lums.edu.pk> List-Id: linux-audit@redhat.com On Tue, Aug 6, 2019 at 11:35 AM Muhammad Adil Inam <20100180@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