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
--
Richard Guy Briggs <rgb(a)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