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

[Richard Guy Briggs]

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 <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

- 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