We're attempting to use slack's go-audit tool to capture/process linux audit events. More info: https://github.com/slackhq/go-audit

The issue is that the linux audit is correctly picking up events, but these are not being picked up by go-audit, or not correctly output by go-audit.

The example go-audit config file has been modified to have a single rule for capturing information about access to a file /opt/secret.txt

- -a exit,always -F path=/opt/secret.txt -F perm=wra -k test_changes

The full go-audit config file is here: https://gist.github.com/tom-chaoscube/fc2f14b448650ea4018620bbbf2c3345

After running go-audit, we can see that this rule has been successfully deployed:

# auditctl -l
-w /opt/secret.txt -p rwa -k test_changes

An attempt to access the file is made, and an audit record can be seen in the audit log file:

$ cat secret.txt
# cat /var/log/audit/audit.log

type=SYSCALL msg=audit(1485357520.702:868): arch=c000003e syscall=2 success=yes exit=3 a0=7ffee46830dc a1=0 a2=1fffffffffff0000 a3=7ffee4681670 items=1 ppid=5199 pid=5469 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts5 ses=7 comm="cat" exe="/usr/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="test_changes"
type=CWD msg=audit(1485357520.702:868):  cwd="/opt"
type=PATH msg=audit(1485357520.702:868): item=0 name="secret.txt" inode=26244598 dev=ca:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:usr_t:s0 objtype=NORMAL

However, when looking at the output from go-audit, no events are recorded. We've tried both with go-audit set to output to stdout, and also to a file.

Running an strace on go-audit, it looks like it's opening up a NETLINK socket, which I assume is the connection to auditd. It can also be seen that some data is received over the socket, in line with periodic entries in the audit.log, however it does not seem like any data is being received specifically when the file access audit entries are written by auditd. (Can't necessarily say this categorically).

socket(PF_NETLINK, SOCK_RAW, 9)         = 4
bind(4, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
setsockopt(4, SOL_SOCKET, SO_RCVBUF, [16384], 4) = 0
getsockopt(4, SOL_SOCKET, SO_RCVBUF, [32768], [4]) = 0
... ...
... ...
write(1, "Started processing events\n", 26) = 26
recvfrom(4, "L\0\0\0\2\0\0\0\1\0\0\0\261\25\0\0\357\377\377\3778\0\0\0\351\3\5\0\1\0\0\0"..., 8970, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 76
futex(0xa0f1d0, FUTEX_WAIT, 0, NULL)    = 0

Any suggestions as to:

  • Why go-audit isn't picking up the events?
  • Further steps that could be taken to investigate if go-audit really is receiving the event information across the socket. (I.e. steps to establish that they are not getting lost on the auditd side)

Edit: I have since tried this locally on Ubunutu 16.10 (as well as the original Centos 7 machine), and have the same results.


  • I suggest you remove Q2 and Q3 and focus on Q1 (Why go-audit isn't picking up the events?) because Q2 is too broad and Q3 is off-topic; this way you risk your post being closed for either reason. – countermode Jan 25 '17 at 15:43
  • Q2 is more intended as "what additional data might help in answering Q1", and I think that is reasonable. Q3 removed. – tomg Jan 25 '17 at 15:49


The answer to this problem is that auditd was still running on the systems.

Simply stopping auditd and restarting go-audit enabled the audit data to be received:

sudo service auditd stop

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.