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

> They would not be safe to access from userspace after the syscall has > finished. audit records the values of a number of specific syscall > parameters in special records so this would most likely need a new > special record to add to the audit syscall event to record those pointer > contents. AFAIK, that would require a patch to the kernel part of the Linux Audit framework?

> This use case adds and additional challenge. Since this is a filesystem > that is changed remotely, you may not have a record of the remote user > who made the change, but only the server daemon locally that brokered > the change unless that information is in those pointers. I know. The username is not a problem because I have Windows/Linux users mapped with Centrify. If I can get the extended attributes updated on the Linux side, I'm hoping my code can infer the equivalent operations on the Windows side. On Sat, Feb 27, 2021 at 6:44 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > On 2021-02-26 22:17, 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? > > They would not be safe to access from userspace after the syscall has > finished. audit records the values of a number of specific syscall > parameters in special records so this would most likely need a new > special record to add to the audit syscall event to record those pointer > contents. > > > 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. > > This use case adds and additional challenge. Since this is a filesystem > that is changed remotely, you may not have a record of the remote user > who made the change, but only the server daemon locally that brokered > the change unless that information is in those pointers. > > > Thanks in advance. > > - RGB