8 entries

Linux auditd

Kernel-level audit records, and how to read a multi-line audit event.

ADD_USER auditd ADD_USER: an account was created Investigate A user account was added. Like the other user-management record types, auditd writes it with no rules configured — so on a machine where nobody set up auditing, this is still one of the few high-value events you will find in the log.
ANOM_ABEND auditd ANOM_ABEND: a process was killed by a signal Worth a look A program died on a signal rather than exiting normally — most often a segmentation fault. auditd records it without any rule being configured, which makes it the one crash record you can rely on being present on a stock Linux system.
AVC SELinux: avc denied — a policy blocked something Worth a look SELinux refused an operation that ordinary file permissions would have allowed. The message names the process, what it wanted, and what it wanted it on — in SELinux's own vocabulary of labels, which is the only genuinely hard part of reading it.
CONFIG_CHANGE auditd type=CONFIG_CHANGE: the audit rules themselves changed Investigate Someone changed what the audit system records. Every other audit rule depends on this one staying honest, which makes an unexplained rule change more significant than almost anything those rules were watching for.
EXECVE auditd EXECVE: a command was executed Informational The Linux audit framework recorded a program being run, with every argument. Unlike sudo logging it works at the kernel level, so it keeps recording after someone obtains a root shell — which is precisely where sudo's audit trail ends.
PATH auditd type=PATH: which file the operation actually touched Informational The PATH records name the files involved in an audited operation. One action usually produces several of them, and only one is the file you care about — the nametype field is what tells you which, and it is the field most people never read.
SYSCALL auditd type=SYSCALL: the record everything else hangs off Worth a look A single audited action produces several lines that all share one event ID. SYSCALL is the spine of that group — it says which kernel call was made, whether it worked, and by whom, and every other line in the event describes some part of it.
USER_AUTH auditd USER_AUTH: an authentication attempt was recorded Worth a look The audit framework recorded an authentication attempt and its result. It covers the same ground as the syslog authentication messages but in a structured, harder-to-tamper-with form, which is why compliance regimes ask for it specifically.