* Getting the value of a syscall's memory address argument - setxattr @ 2021-02-27 1:17 Alan Evangelista 2021-02-27 21:44 ` Richard Guy Briggs 2021-03-02 15:27 ` Steve Grubb 0 siblings, 2 replies; 5+ messages in thread From: Alan Evangelista @ 2021-02-27 1:17 UTC (permalink / raw) To: linux-audit [-- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Getting the value of a syscall's memory address argument - setxattr 2021-02-27 1:17 Getting the value of a syscall's memory address argument - setxattr Alan Evangelista @ 2021-02-27 21:44 ` Richard Guy Briggs 2021-03-01 10:24 ` Alan Evangelista 2021-03-02 15:27 ` Steve Grubb 1 sibling, 1 reply; 5+ messages in thread From: Richard Guy Briggs @ 2021-02-27 21:44 UTC (permalink / raw) To: Alan Evangelista; +Cc: linux-audit 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Getting the value of a syscall's memory address argument - setxattr 2021-02-27 21:44 ` Richard Guy Briggs @ 2021-03-01 10:24 ` Alan Evangelista 2021-03-02 16:55 ` Richard Guy Briggs 0 siblings, 1 reply; 5+ messages in thread From: Alan Evangelista @ 2021-03-01 10:24 UTC (permalink / raw) To: Richard Guy Briggs; +Cc: linux-audit [-- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Getting the value of a syscall's memory address argument - setxattr 2021-03-01 10:24 ` Alan Evangelista @ 2021-03-02 16:55 ` Richard Guy Briggs 0 siblings, 0 replies; 5+ messages in thread From: Richard Guy Briggs @ 2021-03-02 16:55 UTC (permalink / raw) To: Alan Evangelista; +Cc: linux-audit 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Getting the value of a syscall's memory address argument - setxattr 2021-02-27 1:17 Getting the value of a syscall's memory address argument - setxattr Alan Evangelista 2021-02-27 21:44 ` Richard Guy Briggs @ 2021-03-02 15:27 ` Steve Grubb 1 sibling, 0 replies; 5+ messages in thread From: Steve Grubb @ 2021-03-02 15:27 UTC (permalink / raw) To: linux-audit 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-03-02 16:55 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-27 1:17 Getting the value of a syscall's memory address argument - setxattr Alan Evangelista 2021-02-27 21:44 ` Richard Guy Briggs 2021-03-01 10:24 ` Alan Evangelista 2021-03-02 16:55 ` Richard Guy Briggs 2021-03-02 15:27 ` Steve Grubb
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).