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

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


  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
2021-03-02 16:55     ` Richard Guy Briggs [this message]
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=20210302165525.GV3141668@madcap2.tricolour.ca \
    --to=rgb@redhat.com \
    --cc=alan.vitor@gmail.com \
    --cc=linux-audit@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