Getting the value of a syscall's memory address argument - setxattr

[Steve Grubb]

Hello,

On Friday, February 26, 2021 8:17:00 PM EST Alan Evangelista wrote:
> Each syscall has some arguments and the Linux Audit framework logs each
> pointer argument as a memory address instead of its values. For instance,
> when tracking the setxattr syscall, I get its arguments in the following
> format:
> 
> "a0":"55f3604ba000"
> "a1":"7f1b0bd342fd"
> "a2":"55f3604d9b20"
> "a3":"38"
> 
> According to https://man7.org/linux/man-pages/man2/setxattr.2.html, a0 is
> the file path's starting memory address, a1 is the extended attribute
> name's starting memory address, a2 is the extended attribute
> value's starting memory address and a3 is the size in bytes of the extended
> attribute value.
> 
> Is it safe to access those memory addresses in order to get their values? I
> guess not because their content may have been overwritten between the time
> the syscall log entry was generated by the kernel and the time it's
> consumed by a Linux Audit client. If indeed it's unsafe to access these
> memory addresses, is there any other way to get the extended attribute
> name/value in the setxattr syscall using the Linux Audit framework?

Now that you mention it, we should probably have a xattr record that records 
all those things. It is not safe to directly access those values, but it can 
be done after copy_from_user makes a safe to access copy. We have issue 39 
which is supposed to capture arg 4, but I think it's scope should be 
expanded.

https://github.com/linux-audit/audit-kernel/issues/39

-Steve

> My specific use case: I'm using Auditbeat/Linux Audit to track permission
> changes done to a disk partition which is mounted by Samba on a Windows
> Server box. When a Windows user changes permissions of a file in the Samba
> mount, Linux Audit records a setxattr event and Auditbeat (connected to the
> kernel's Audit framework via netlink) notifies me of the event. I need to
> know what permission changes the user has done in the file and AFAIK
> parsing the ext attrib name/value is the only way to do that.
> 
> Thanks in advance.