All of lore.kernel.org
 help / color / mirror / Atom feed
* Auditd SYSCALL argument decoding
@ 2019-11-19 17:24 Tim Galyean
  2019-11-19 22:26 ` Richard Guy Briggs
  2019-11-19 22:34 ` Steve Grubb
  0 siblings, 2 replies; 4+ messages in thread
From: Tim Galyean @ 2019-11-19 17:24 UTC (permalink / raw)
  To: linux-audit


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

Hello,

As I understand it, long values recorded by auditd are stored as hex encoded strings. However, when I attempt to decode arguments such as a0 or a1 in SYSCALL events, they are decoded into special characters instead of ASCII. Are these values encoded differently than PROCTITLE events?

Below is an example log line:

type=SYSCALL msg=audit(1574182099.559:2002): arch=c000003e syscall=59 success=yes exit=0 a0=55df330a3c10 a1=55df330a3c78 a2=55df330a3c90 a3=0 items=3 ppid=29664 pid=29678 auid=1171 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=170 comm="apt-check" exe="/usr/bin/python3.5" key="rootcmd"

In this example, I am looking to decode a0, a1, and a2. Yes, it seems that ausearch can decode these values. However, I am looking to decode them via Splunk. What format are these strings encoded in and is there a way to decode these values in any other way other than by using ausearch?

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

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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Auditd SYSCALL argument decoding
  2019-11-19 17:24 Auditd SYSCALL argument decoding Tim Galyean
@ 2019-11-19 22:26 ` Richard Guy Briggs
  2019-11-19 22:34 ` Steve Grubb
  1 sibling, 0 replies; 4+ messages in thread
From: Richard Guy Briggs @ 2019-11-19 22:26 UTC (permalink / raw)
  To: Tim Galyean; +Cc: linux-audit

On 2019-11-19 17:24, Tim Galyean wrote:
> Hello,
> 
> As I understand it, long values recorded by auditd are stored as hex encoded strings. However, when I attempt to decode arguments such as a0 or a1 in SYSCALL events, they are decoded into special characters instead of ASCII. Are these values encoded differently than PROCTITLE events?

They are unsigned long long integers printed in hexadecimal, which is
the pointer size on 64-bit architectures.  These are pointers to the
memory location containing the string, so we don't actually have the
string value.

> Below is an example log line:
> 
> type=SYSCALL msg=audit(1574182099.559:2002): arch=c000003e syscall=59 success=yes exit=0 a0=55df330a3c10 a1=55df330a3c78 a2=55df330a3c90 a3=0 items=3 ppid=29664 pid=29678 auid=1171 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=170 comm="apt-check" exe="/usr/bin/python3.5" key="rootcmd"
> 
> In this example, I am looking to decode a0, a1, and a2. Yes, it seems that ausearch can decode these values. However, I am looking to decode them via Splunk. What format are these strings encoded in and is there a way to decode these values in any other way other than by using ausearch?

My understanding is that ausearch does not have access to the original
strings to decode them.  The kernel does have access to the full string
at the time of the generation of the message, but does not include it in
the record format due to the lack of knowledge of every syscall format
to know which ones to decode and due to netlink bandwidth and disk
storage limits.

- 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Auditd SYSCALL argument decoding
  2019-11-19 17:24 Auditd SYSCALL argument decoding Tim Galyean
  2019-11-19 22:26 ` Richard Guy Briggs
@ 2019-11-19 22:34 ` Steve Grubb
  2019-11-20 12:24   ` Tim Galyean
  1 sibling, 1 reply; 4+ messages in thread
From: Steve Grubb @ 2019-11-19 22:34 UTC (permalink / raw)
  To: Tim Galyean; +Cc: linux-audit

On Tue, 19 Nov 2019 17:24:21 +0000
Tim Galyean <tgalyean@splunk.com> wrote:

> Hello,
> 
> As I understand it, long values recorded by auditd are stored as hex
> encoded strings. However, when I attempt to decode arguments such as
> a0 or a1 in SYSCALL events, they are decoded into special characters
> instead of ASCII. Are these values encoded differently than PROCTITLE
> events?
> 
> Below is an example log line:
> 
> type=SYSCALL msg=audit(1574182099.559:2002): arch=c000003e syscall=59
> success=yes exit=0 a0=55df330a3c10 a1=55df330a3c78 a2=55df330a3c90
> a3=0 items=3 ppid=29664 pid=29678 auid=1171 uid=0 gid=0 euid=0 suid=0
> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=170 comm="apt-check"
> exe="/usr/bin/python3.5" key="rootcmd"
> 
> In this example, I am looking to decode a0, a1, and a2. Yes, it seems
> that ausearch can decode these values. However, I am looking to
> decode them via Splunk.

Please have auparse decode them. This is well maintained and accurate.
Sometimes they point to memory. Sometimes they have meaning. All of
this is encoded in the auparse library. Let me know if you have any
issues decoding anything via libauparse.

> What format are these strings encoded in and is there a way to
> decode these values in any other way other than by using ausearch?

Libauparse is what ausearch uses. It has all knowledge encoded within
it. It detangles intertwined events as well as normal events.

-Steve

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Auditd SYSCALL argument decoding
  2019-11-19 22:34 ` Steve Grubb
@ 2019-11-20 12:24   ` Tim Galyean
  0 siblings, 0 replies; 4+ messages in thread
From: Tim Galyean @ 2019-11-20 12:24 UTC (permalink / raw)
  To: Steve Grubb; +Cc: linux-audit

Thank you both for the additional information. This would explain why I was seeing values like, a0=0x27489e8, when I was using --interpret with ausearch. 
 

On 11/19/19, 4:34 PM, "Steve Grubb" <sgrubb@redhat.com> wrote:

    [--- This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. ---]
    
    On Tue, 19 Nov 2019 17:24:21 +0000
    Tim Galyean <tgalyean@splunk.com> wrote:
    
    > Hello,
    > 
    > As I understand it, long values recorded by auditd are stored as hex
    > encoded strings. However, when I attempt to decode arguments such as
    > a0 or a1 in SYSCALL events, they are decoded into special characters
    > instead of ASCII. Are these values encoded differently than PROCTITLE
    > events?
    > 
    > Below is an example log line:
    > 
    > type=SYSCALL msg=audit(1574182099.559:2002): arch=c000003e syscall=59
    > success=yes exit=0 a0=55df330a3c10 a1=55df330a3c78 a2=55df330a3c90
    > a3=0 items=3 ppid=29664 pid=29678 auid=1171 uid=0 gid=0 euid=0 suid=0
    > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=170 comm="apt-check"
    > exe="/usr/bin/python3.5" key="rootcmd"
    > 
    > In this example, I am looking to decode a0, a1, and a2. Yes, it seems
    > that ausearch can decode these values. However, I am looking to
    > decode them via Splunk.
    
    Please have auparse decode them. This is well maintained and accurate.
    Sometimes they point to memory. Sometimes they have meaning. All of
    this is encoded in the auparse library. Let me know if you have any
    issues decoding anything via libauparse.
    
    > What format are these strings encoded in and is there a way to
    > decode these values in any other way other than by using ausearch?
    
    Libauparse is what ausearch uses. It has all knowledge encoded within
    it. It detangles intertwined events as well as normal events.
    
    -Steve
    
    


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-11-20 12:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-19 17:24 Auditd SYSCALL argument decoding Tim Galyean
2019-11-19 22:26 ` Richard Guy Briggs
2019-11-19 22:34 ` Steve Grubb
2019-11-20 12:24   ` Tim Galyean

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.