What's stopping auditd from logging writes by Syslog when watching a Syslog file?

Question

We've recently started using auditd on one of our Ubuntu servers.

The example audit.rules file we were given has a rule like this:

-w /var/log/syslog -p wra -k logs

However, when syslog writes to the file, nothing gets logged by auditd. Similarly, if I go to the command line and run the logger command, the syslog file gets written without generating an audit log. If I alter the file directly by using an editor or appending a line to it from the command line, it does get logged.

Of course, I don't want an audit log every time syslog gets written, but I'm interested to know what causes this to happen and if there are any other cases besides syslog where this could be happening without my knowledge.

Thank you very much!

Additional info:

Test audit.rules file:

-D
-b 8192
-f 1
-w /var/log/syslog -p wra -k logs

Output of auditctl -l and augenrules --check:

# auditctl -l
-w /var/log/syslog -p rwa -k logs

# augenrules --check
/sbin/augenrules: Rules have changed and should be updated

Using logger:

# logger "logger example"
# ausearch -k logs
----
time->Fri Mar 10 14:35:20 2017
type=CONFIG_CHANGE msg=audit(1489156520.983:4463): auid=4294967295 ses=4294967295 op="add_rule" key="logs" list=4 res=1

Using echo and output redirect:

# echo "echo example" >> /var/log/syslog
# ausearch -k logs
----
time->Fri Mar 10 14:35:20 2017
type=CONFIG_CHANGE msg=audit(1489156520.983:4463): auid=4294967295 ses=4294967295 op="add_rule" key="logs" list=4 res=1
----
time->Fri Mar 10 14:36:52 2017
type=PROCTITLE msg=audit(1489156612.334:4465): proctitle="bash"
type=PATH msg=audit(1489156612.334:4465): item=1 name="/var/log/syslog" inode=417506 dev=08:01 mode=0100640 ouid=104 ogid=4 rdev=00:00 nametype=NORMAL
type=PATH msg=audit(1489156612.334:4465): item=0 name="/var/log/" inode=411799 dev=08:01 mode=040775 ouid=0 ogid=108 rdev=00:00 nametype=PARENT
type=CWD msg=audit(1489156612.334:4465):  cwd="/etc/audit"
type=SYSCALL msg=audit(1489156612.334:4465): arch=c000003e syscall=2 success=yes exit=3 a0=a93108 a1=441 a2=1b6 a3=7ffe24385b98 items=2 ppid=28462 pid=28463 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts18 ses=4294967295 comm="bash" exe="/bin/bash" key="logs"

Tail of /var/log/syslog:

# tail -n 2 /var/log/syslog
Mar 10 14:36:40 testserver root: logger example
echo example

Answer 1

I've understood the reason behind this behavior.

The auditctl man page for the -p flag states:

Describe the permission access type that a file system watch will trigger on. r=read, w=write, x=execute, a=attribute change. These permissions are not the standard file permissions, but rather the kind of syscall that would do this kind of thing. The read & write syscalls are omitted from this set since they would overwhelm the logs. But rather for reads or writes, the open flags are looked at to see what permission was requested.

I didn't understand what this meant at the time, but after a couple of hours digging into the linux-audit mailing list, I've come to realize this means that if you watch a file for writing, it doesn't log when there's a syscall for writing to the file. It just logs if a file was accessed with write permissions by checking for open syscalls with the O_RDWR or O_WRONLY flags.

So, when I use the logger command, I'm actually asking my Syslog daemon to write to the file for me. The syslog daemon always has that file open for writing, therefore it makes sense that nothing gets logged.

If I restart the Syslog daemon, I get something like this on my audit logs:

# ausearch -i -k logs
----
type=PROCTITLE msg=audit(10-03-2017 16:16:59.128:4613) : proctitle=/usr/sbin/rsyslogd -n 
type=PATH msg=audit(10-03-2017 16:16:59.128:4613) : item=1 name=/var/log/syslog inode=417506 dev=08:01 mode=file,640 ouid=syslog ogid=adm rdev=00:00 nametype=NORMAL 
type=PATH msg=audit(10-03-2017 16:16:59.128:4613) : item=0 name=/var/log/ inode=411799 dev=08:01 mode=dir,775 ouid=root ogid=syslog rdev=00:00 nametype=PARENT 
type=CWD msg=audit(10-03-2017 16:16:59.128:4613) :  cwd=/ 
type=SYSCALL msg=audit(10-03-2017 16:16:59.128:4613) : arch=x86_64 syscall=open success=yes exit=6 a0=0x7f5848003fb0 a1=O_WRONLY|O_CREAT|O_NOCTTY|O_APPEND|O_CLOEXEC a2=0640 a3=0x7f5848000088 items=2 ppid=1 pid=10638 auid=unset uid=syslog gid=syslog euid=syslog suid=syslog fsuid=syslog egid=syslog sgid=syslog fsgid=syslog tty=(none) ses=unset comm=rs:main Q:Reg exe=/usr/sbin/rsyslogd key=logs

Answer 2

You can start by checking whether the rule is currently active by looking for it in the output of sudo auditctl -l.

If auditd was set to make the ruleset immutable (e.g. your /etc/audit/audit.rules contains -e 2), then only a reboot would make new rules active.

If the rule is visible, do you get anything if you run sudo ausearch -k logs? Also, what do you get if you run sudo augenrules --check?

As you say, logging every write to the /var/log/syslog (or /var/log/messages) could get a little noisy, so you might consider excluding root and/or whichever user is used for unprivileged syslog components. Once it works.