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

[Alan Evangelista]

> 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 at 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
>
> --
> Richard Guy Briggs <rgb at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20210301/a0bfef02/attachment.htm>