Recently, we've enabled auditd on one of our CentOS 7.3 servers and while reviewing some basic reports, I've noticed there's a ton of failed events, say around ~10K a day:
# aureport -x --failed | grep 03/29 | wc -l
10454
I'm trying to understand what are some of those failed events, but I'm not getting far. Example of one of more common ones, event 8339524:
grep 8339524 audit.log
audit.log:node=hostname1.internal type=SYSCALL msg=audit(1490796601.096:8339524): arch=c000003e syscall=2 success=no exit=-6 a0=4a9037 a1=802 a2=6eb028 a3=7ffe761484d0 items=1 ppid=16090 pid=16094 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=301903 comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 key="root"
audit.log:node=hostname1.internal type=PATH msg=audit(1490796601.096:8339524): item=0 name="/dev/tty" inode=1036 dev=00:05 mode=020666 ouid=0 ogid=5 rdev=05:00 obj=system_u:object_r:devtty_t:s0 objtype=NORMAL
I can see that user root executed a 'sh' command but what exactly has been launched, i.e., what's happening on the system? I'm aware of having ausearch interpret the event in human readable form, but that doesn't seem to convey much new intel:
# ausearch --interpret -a 8339524
----
node=hostname1.internal type=PATH msg=audit(03/29/2017 16:10:01.096:8339524) : item=0 name=/dev/tty inode=1036 dev=00:05 mode=character,666 ouid=root ogid=tty rdev=05:00 obj=system_u:object_r:devtty_t:s0 objtype=NORMAL
node=hostname1.internal type=SYSCALL msg=audit(03/29/2017 16:10:01.096:8339524) : arch=x86_64 syscall=open success=no exit=ENXIO(No such device or address) a0=0x4a9037 a1=O_RDWR|O_NONBLOCK a2=0x6eb028 a3=0x7ffe761484d0 items=1 ppid=16090 pid=16094 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=301903 comm=sh exe=/usr/bin/bash subj=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 key=root
is that an issue with opening /dev/tty? Since the device file is there and looks just like other terminals. Also, does subj=system_u:system_r:system_cronjob_t suggest that's a cron job related thing? The only entry in server's crontab is set to run at */3 every hour, so it doesn't correspond to event's 16:10 timestamp.
