Linux-audit Archive on lore.kernel.org
 help / color / Atom feed
From: Alan Evangelista <alan.vitor@gmail.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: Getting the value of a syscall's memory address argument - setxattr
Date: Mon, 1 Mar 2021 07:24:50 -0300
Message-ID: <CAKz+TUsWRMx3c6zGUzRzbTaS=1-7oOmyZvdv-Fv68-Oag=JxTQ@mail.gmail.com> (raw)
In-Reply-To: <20210227214432.GT2015948@madcap2.tricolour.ca>

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

  reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-27  1:17 Alan Evangelista
2021-02-27 21:44 ` Richard Guy Briggs
2021-03-01 10:24   ` Alan Evangelista [this message]
2021-03-02 16:55     ` Richard Guy Briggs
2021-03-02 15:27 ` Steve Grubb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKz+TUsWRMx3c6zGUzRzbTaS=1-7oOmyZvdv-Fv68-Oag=JxTQ@mail.gmail.com' \
    --to=alan.vitor@gmail.com \
    --cc=linux-audit@redhat.com \
    --cc=rgb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-audit Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-audit/0 linux-audit/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-audit linux-audit/ https://lore.kernel.org/linux-audit \
		linux-audit@redhat.com
	public-inbox-index linux-audit

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.redhat.linux-audit


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git