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

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

[Alan Evangelista]

[-- Attachment #1.1: Type: text/plain, Size: 1551 bytes --]

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?

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.

Thanks in advance.

[-- Attachment #1.2: Type: text/html, Size: 1924 bytes --]

[-- Attachment #2: Type: text/plain, Size: 106 bytes --]

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

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

[Richard Guy Briggs]

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

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

[Alan Evangelista]

[-- Attachment #1.1: Type: text/plain, Size: 3506 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 4468 bytes --]

[-- Attachment #2: Type: text/plain, Size: 106 bytes --]

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

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

[Steve Grubb]

Hello,

On Friday, February 26, 2021 8:17:00 PM EST 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?

Now that you mention it, we should probably have a xattr record that records 
all those things. It is not safe to directly access those values, but it can 
be done after copy_from_user makes a safe to access copy. We have issue 39 
which is supposed to capture arg 4, but I think it's scope should be 
expanded.

https://github.com/linux-audit/audit-kernel/issues/39

-Steve

> 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.
> 
> Thanks in advance.




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: 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@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@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