2

I have the following situation in hand. I have one or more specific execuatble files in /usr/bin, I will call one /usr/bin/execute , and they may either be a compiled binary or a script file, such as a perl or python script.

I would like to log when any user launches these specific binaries. The information I would like from this is basically:

  • the name/path of the executable
  • the arguments given to the executable
  • the user who performed the action
  • the date/time

Furthermore, I would like this information to be in a format which is logical to parse if needed.

Auditd looked like a good choice at first, but it has a strange way of splitting up the information above into two entries for some reason. For example, in the example above, I want to track running of the program /usr/bin/execute. I will add these statements to the auditctl:

-a exit,always -F arch=b32 -S execve
-a exit,always -F arch=b64 -S execve

(I have not yet been able to find how to specify "/usr/bin/execute" as the only thing logged, I would appreciate help from someone who knows how to do this)

In the log after running /usr/bin/execute with one argument, I get the following two relevent entries:

type=SYSCALL msg=audit(1447688181.106:819746): arch=c000003e syscall=59 success=yes exit=0 a0=2898528 a1=26e3308 a2=2720008 a3=7fff176c1840 items=3 ppid=10697 pid=10715 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts4 ses=8 comm="execute" exe="/usr/bin/perl" key=(null)
type=EXECVE msg=audit(1447688181.106:819746): argc=3 a0="/usr/bin/perl" a1="/usr/bin/execute" a2="some_arg.txt"

The information is for some reason being split between two entries. In the first SYSCALL message I get the uid of the user, and in the second EXECVE message I get the path (in 'a1', which I am not sure is consistant) and the arguments. In addition to the fact that this is more difficult to parse, I do not have a definite link between these statements to reconcile that they are part of the same event. This whole output seems to be generally incorrect for what I am trying to accomplish, so I am looking for a better way.

Tl;Dr: Can I get auditd to log this information to a file in a generally parse-able way, for scripts or binaries? Can I limit logging to only this executable file? If not, would another auditing daemon be a better choice?

Thank you.

0

No matter how you do this in auditd you will have to use some parser to get the information you want (unless one of ausearch's options will help).

To start with, to monitor just specific commands, and lets say the commands are /usr/bin/who (a binary) and /usr/bin/whatis (a shell script), then use the rules

-w /usr/bin/who -p x -k my_execs
-w /usr/bin/whatis -p x -k my_execs

After setting these rules, restart the auditd service, then execute

who -a
whatis who

then as root

ausearch -i -k my_execs

to get

----
node=mynode.mydomain type=CONFIG_CHANGE msg=audit(11/18/2015 08:38:22.724:847290) : auid=burn ses=145 subj=unconfined_u:system_r:auditctl_t:s0 op="add rule" key=my_execs list=exit res=yes
----
node=mynode.mydomain type=CONFIG_CHANGE msg=audit(11/18/2015 08:38:22.724:847291) : auid=burn ses=145 subj=unconfined_u:system_r:auditctl_t:s0 op="add rule" key=my_execs list=exit res=yes
----
node=mynode.mydomain type=PATH msg=audit(11/18/2015 08:38:25.381:847344) : item=1 name=(null) inode=524297 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL
node=mynode.mydomain type=PATH msg=audit(11/18/2015 08:38:25.381:847344) : item=0 name=/usr/bin/who inode=2102799 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL
node=mynode.mydomain type=CWD msg=audit(11/18/2015 08:38:25.381:847344) :  cwd=/tmp
node=mynode.mydomain type=EXECVE msg=audit(11/18/2015 08:38:25.381:847344) : argc=2 a0=who a1=-a
node=mynode.mydomain type=SYSCALL msg=audit(11/18/2015 08:38:25.381:847344) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x11728e0 a1=0x1172d90 a2=0x10e8020 a3=0x18 items=2 ppid=1810 pid=22443 auid=burn uid=burn gid=burn euid=burn suid=burn fsuid=burn egid=burn sgid=burn fsgid=burn tty=pts0 ses=145 comm=who exe=/usr/bin/who subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=my_execs
----
node=mynode.mydomain type=PATH msg=audit(11/18/2015 08:38:31.052:847381) : item=2 name=(null) inode=524297 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL
node=mynode.mydomain type=PATH msg=audit(11/18/2015 08:38:31.052:847381) : item=1 name=(null) inode=786482 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shell_exec_t:s0 nametype=NORMAL
node=mynode.mydomain type=PATH msg=audit(11/18/2015 08:38:31.052:847381) : item=0 name=/usr/bin/whatis inode=2112811 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL
node=mynode.mydomain type=CWD msg=audit(11/18/2015 08:38:31.052:847381) :  cwd=/tmp
node=mynode.mydomain type=EXECVE msg=audit(11/18/2015 08:38:31.052:847381) : argc=2 a0=/bin/sh a1=/usr/bin/whatis
node=mynode.mydomain type=EXECVE msg=audit(11/18/2015 08:38:31.052:847381) : argc=3 a0=/bin/sh a1=/usr/bin/whatis a2=who
node=mynode.mydomain type=SYSCALL msg=audit(11/18/2015 08:38:31.052:847381) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x1172d90 a1=0x1172500 a2=0x10e8020 a3=0x18 items=3 ppid=1810 pid=22504 auid=burn uid=burn gid=burn euid=burn suid=burn fsuid=burn egid=burn sgid=burn fsgid=burn tty=pts0 ses=145 comm=whatis exe=/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=my_execs

You can see that ausearch has extracted the events you want (using your key). The SYSCALL elements give you the who, where and other elements, the EXECVE elements give you the arguments, the CWD the location and the PATH's details about files involved. For reference on this system the inodes above map to

524297  /lib64/ld-2.12.so
2102799 /usr/bin/who
786482  /bin/bash
2112811 /usr/bin/whatis

You can check out https://people.redhat.com/sgrubb/audit for more information

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.