How to audit user permissions on Linux with auditd

Why monitor critical files on Linux servers?

In any server environment, ensuring the integrity of configuration files and sensitive data is an absolute priority. Traditional Linux permissions, such as owner, group, and others, are useful, but they alone cannot prevent privileged users from making unauthorized changes or stopping malicious actors from altering system binaries. This exact scenario highlights the need for active security auditing, going far beyond what a simple static check like how to audit dangerous file permissions on Linux with find provides in day-to-day administration.

In practice, system auditing acts like a security camera pointed directly at the operating system's core, known as the kernel. When a process attempts to read, write, or execute a monitored file, the kernel records the event in detail within dedicated log files. This means you gain precise visibility into who did what, when the modification took place, and what exact command was executed, eliminating guesswork during security incidents or unexpected infrastructure failures.

What is auditd and how does it integrate with the kernel?

The auditd daemon is the background service responsible for collecting and centralizing security events generated by the Linux kernel's built-in auditing subsystem. Instead of relying on slow periodic scans, auditd intercepts system calls (syscalls, which act as communication gateways between programs and hardware/kernel) the exact moment they happen, ensuring immediate response and preventing the loss of crucial information.

Setting up this tool requires understanding that every disk action goes through strict rules defined by the administrator. The service reads these guidelines from a central configuration file and applies them directly into kernel memory. If someone attempts to bypass these rules, the system logs the event or takes stricter measures depending on configuration rigidity. For those managing complex setups, this precision mirrors the need for rigorous operational control, much like knowing how to restart stuck Kubernetes pods using kubectl when an application behaves abnormally.

Step-by-step: configuring rules to track modifications

To start monitoring sensitive system files, such as the user password database /etc/passwd, we need to add specific rules to the auditing subsystem. The utility command for interacting with these rules at runtime is auditctl, but permanent rules must be saved in the service configuration file to persist across server reboots.

1. Open the persistent audit rules configuration file using your preferred text editor with superuser privileges.
2. Add the monitoring line pointing to the target file along with write permissions and an identifying key:

   -w /etc/passwd -p wa -k passwd_changes

3. Restart the auditd service to immediately apply the new rules into the operating system's kernel:

   sudo systemctl restart auditd

In the example above, the flag -w defines the path to watch, the flag -p wa instructs auditd to trigger an alert whenever write attempts (w) or attribute modifications (a) occur, and the flag -k adds a descriptive keyword tag to simplify future log searches.

How to query and analyze auditd logs

With active rules in place, any modification to /etc/passwd will generate dozens of detailed log lines in the default audit directory. Reading these raw files directly can be tedious due to the volume of kernel metadata generated every microsecond. To filter only what matters quickly and efficiently, we use the built-in search utility called ausearch.

The usefulness of ausearch lies in its ability to cross-reference data using the tags we created in our rules. By running sudo ausearch -k passwd_changes, the system scans the log file and returns a readable summary containing the exact timestamp of the change, the numeric User ID (UID) responsible, the originating process, and the operation result. This granular visibility is vital for security teams needing quick responses during compliance audits and digital forensics.

Final considerations on continuous auditing

Implementing auditd in your Linux ecosystem transforms your security posture from reactive to proactive. Knowing precisely who modified a critical file on production servers eliminates blind spots and discourages malicious internal or external actions. Although it requires planning to avoid generating excessive noise, the gain in traceability vastly outweighs the initial setup effort, keeping your corporate environment solid and fully auditable.