Audit Filtering on Executable Pathname

As part of Linux 4.3 we added the
ability to selectively filter based on an executable pathname and not just
the executable’s current PID. This post is a quick introduction to the new
functionality using ‘/usr/bin/echo’ as a simple example.

In order to use the new audit by executable functionality you need to make
sure you are running Linux 4.3 or greater, and the audit userspace tools
version 2.5 or greater. For this example I’m using a Fedora Rawhide system
with a Linux 4.5 development kernel
and the audit v2.5 userspace.

# uname -r

4.5.0-0.rc3.git0.1.secnext.1.fc24.x86_64

# rpm -q audit

audit-2.5-1.fc24.x86_64

First, I’m going to clear any existing audit rules from the system and create a
new rule to generate an audit event whenever the ‘/usr/bin/echo’ application
calls the write() system call; I’m also going to have the kernel mark these
records with the ‘testing’ key for easier parsing by ‘ausearch’ later. It is
important to note that this is just a simple example to demonstrate the
functionality, the new ‘-F exe=…’ audit filter can used as part of larger,
more complex rules.

# auditctl -D

# auditctl -a always,exit -F arch=b64 -S write -F exe=/usr/bin/echo -k testing

With the new rule loaded into the kernel we simply need to execute
‘/usr/bin/echo’. It is important to specify the full path for the echo
command as some shells, including bash, default to a built-in if an absolute
executable path for echo is not given.

# /usr/bin/echo "hello world!"

We can now check the audit log to see if any events have occurred that match
the ‘testing’ key we used when we created our new audit by executable rule.

# ausearch -i -k testing

----

type=CONFIG_CHANGE msg=audit(02/12/2016 16:41:00.931:160) : auid=root ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op="add_rule" key=testing list=exit res=yes 

----

type=PROCTITLE msg=audit(02/12/2016 16:41:08.347:161) : proctitle=/usr/bin/echo hello world! 

type=SYSCALL msg=audit(02/12/2016 16:41:08.347:161) : arch=x86_64 syscall=write success=yes exit=13 a0=0x1 a1=0x561daea04030 a2=0xd a3=0x561daea04030 items=0 ppid=881 pid=1057 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=2 comm=echo exe=/usr/bin/echo subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=testing

In this case we see two audit events have been recorded in the audit log. The
first event consists of a single CONFIG_CHANGE record and was generated
when we loaded the new rule into the kernel. The second event was generated
by our newly created audit by executable rule and show ‘/usr/bin/echo’ using
the write() syscall. For such a simple application as ‘/bin/true’ this is
exactly what we would expect, and an indication that everything is working
correctly.