0

I configured my auditd to log all execve syscalls using these rules:

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

While this perfectly captures all activity of any user on the system, obviously there is a lot of noise as well. I've added a few exceptions, like:

-a exit,never -F arch=b32 -S execve -F exe=/bin/date
-a exit,never -F arch=b64 -S execve -F exe=/bin/date

Now the only noise left, that I'd still like to exclude is the execution of some scripts, through /bin/sh. The auserach output of those looks like this:

type=PROCTITLE msg=audit(03/21/19 13:35:01.579:7561) : proctitle=/bin/sh /usr/lib/sysstat/debian-sa1 1 1 
type=PATH msg=audit(03/21/19 13:35:01.579:7561) : item=2 name=/lib64/ld-linux-x86-64.so.2 inode=2228626 dev=fc:01 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 
type=PATH msg=audit(03/21/19 13:35:01.579:7561) : item=1 name=/bin/sh inode=1572884 dev=fc:01 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 
type=PATH msg=audit(03/21/19 13:35:01.579:7561) : item=0 name=/usr/lib/sysstat/debian-sa1 inode=1968913 dev=fc:01 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 
type=EXECVE msg=audit(03/21/19 13:35:01.579:7561) : argc=4 a0=/bin/sh a1=/usr/lib/sysstat/debian-sa1 a2=1 a3=1 
type=SYSCALL msg=audit(03/21/19 13:35:01.579:7561) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x561ccb6c2510 a1=0x561ccb6c24b0 a2=0x561ccb6c24d0 a3=0x7fc8166fd810 items=3 ppid=16157 pid=16158 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=52 comm=debian-sa1 exe=/bin/dash key=exec

So /usr/lib/sysstat/debian-sa1 is executed using /bin/sh (which in this case is a link to /bin/dash). Here I obviously don't want to exclude all executions of /bin/sh or /bin/dash, but only those to a handful of scripts I'm allowing.

Is there a way to specify such an exception? I tried something like this:

-a exit,never -F arch=b32 -S execve -F exe=/bin/dash -F path=/usr/lib/sysstat/debian-sa1
-a exit,never -F arch=b64 -S execve -F exe=/bin/dash -F path=/usr/lib/sysstat/debian-sa1
-a exit,never -F arch=b32 -S execve -F exe=/usr/lib/sysstat/debian-sa1
-a exit,never -F arch=b64 -S execve -F exe=/usr/lib/sysstat/debian-sa1

but that didn't work.

According to man auditctl(8) it's also not possible to check a0,a1,... for a string, as pointers are used there. Am I missing something here, or is this simply not possible?

KlausB
  • 3
  • 2

1 Answers1

1

Correct, there isn't a practical way in audit rules to distinguish execve for same interpreter different scripts. What to do depends on your goal with collecting this information.

If you want to survey how many execves and what they run, you'll have to come up with a way to parse and filter them.

If you are watching some person or service account's non privileged activity, audit that user and not root.

For watching security boundaries however, you don't need everything. Much more interesting is when the euid becomes root. From the compliance examples in the documenation, consider rules/30-pci-dss-v31.rules

## 10.2.5.b All elevation of privileges is logged
-a always,exit -F arch=b64 -S setuid -F a0=0 -F exe=/usr/bin/su -F key=10.2.5.b-elevated-privs-session
-a always,exit -F arch=b32 -S setuid -F a0=0 -F exe=/usr/bin/su -F key=10.2.5.b-elevated-privs-session
-a always,exit -F arch=b64 -S setresuid -F a0=0 -F exe=/usr/bin/sudo -F key=10.2.5.b-elevated-privs-session
-a always,exit -F arch=b32 -S setresuid -F a0=0 -F exe=/usr/bin/sudo -F key=10.2.5.b-elevated-privs-session
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=10.2.5.b-elevated-privs-setuid
-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -F key=10.2.5.b-elevated-privs-setuid
John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Thanks for the reply. Your suggestion is interesting. However, I made a slight adaption, by comparing `auid!=euid` as this also catches all executions after someone used `sudo su`. – KlausB Mar 25 '19 at 10:26