On 2021-03-01 07:24, Alan Evangelista wrote: > > 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?
Yes. See: https://github.com/linux-audit/audit-kernel/issues/39 > > 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 <r...@redhat.com> 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 - RGB -- Richard Guy Briggs <r...@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
