Your Linux fleet owner refuses a fleet-wide auditd execve rule on CPU and disk grounds - what now?

## Why this is a negotiation and not a configuration task On Linux there is no execution audit trail until someone writes a rule. The kernel audit subsystem records what its rules tell it to, so a rule like an `always,exit` filter on the `execve` syscall for the 64-bit architecture, tagged with a key, is the difference between a fleet you can investigate and one you cannot. That rule lives in a configuration the platform team owns, on hosts whose performance they are accountable for. Winning the argument on merit is the job. ## Taking the cost claim apart **The CPU claim.** Audit rules are evaluated in the syscall path, so cost scales with the *frequency of the audited syscall*. The reputation auditd has for being expensive comes from broad rule packs that audit file opens, writes, network calls and permission changes on busy servers. Process execution is orders of magnitude rarer than file I/O on a typical server. An execve-only rule is therefore not the thing being objected to — but it is what the fleet owner heard, because previous requests asked for everything. **The disk and wire claim.** This one usually survives scrutiny, and the reason is instructive: **your own automation dominates the volume.** A configuration-management run — Ansible, Salt, Puppet, a deployment pipeline — executes many short-lived processes per host per run, and each execution produces a record group: the `SYSCALL` record with `pid`, `ppid`, `uid`, `auid` and the result, an `EXECVE` record carrying the arguments split as `a0`, `a1`, `a2` (hex-encoded when they contain awkward characters), plus `CWD` and `PATH` records, all joined by one event serial number. Multiply by the fleet and the run cadence and the number is genuinely large. That same fact is the leaf's other lesson: **a configuration-management push is indistinguishable in shape from mass remote execution across the fleet.** It is this category's benign true positive, and if you do not know your own automation's identity and pattern, you will either chase it or, worse, learn to ignore the shape entirely. ## What to negotiate for - **Scope the kernel rule tightly, not the wrong way.** Ask for execve on the architectures actually in use, keyed for retrieval, and do not ask for broad file or network syscall auditing in the same breath. Conceding what you do not need is what makes the remaining ask credible. - **Reduce volume downstream, not at the kernel.** Once records exist you have choices about what to forward and how long to keep it. Filtering at the kernel means the evidence never existed. - **Do not simply drop the automation account.** It is the obvious saving and it is a hole you must name aloud: an intruder who runs through the same orchestration path, or with the same service identity, disappears with the filter. If you must reduce it, reduce by *volume sampling with full retention of anything unusual*, and say what you traded. - **Use `auid`.** The login uid is recorded per process and survives `su` and `sudo`, so a root-owned process still carries the identity of the human session behind it; daemon-spawned processes carry an unset value. It is the single most useful field for separating your automation from a person, and it is also what makes selective handling defensible rather than blind. - **Watch for silent loss.** The audit backlog has a limit; when it is exceeded, records are dropped and the `lost` counter rises. A gap you know about is manageable; a gap you do not is a false sense of coverage. Ask for the backlog setting and monitoring of that counter as part of the deal. - **Bring a measured pilot.** One ring of hosts, real bytes per host per day, real CPU deltas under the fleet's actual workload. Arguments lose to numbers, in both directions — and if the numbers say the objection was right, you have learned something worth knowing. ## The part that makes this a leadership question You may lose. The professional outcome then is not to shrug: it is to make the loss **explicit and owned**. Write down the questions the fleet cannot answer without execution records — what ran, under whose login, with what arguments, in what order — state that an intrusion on those hosts will be unreconstructable, and have the fleet owner accept that named risk with a review date. Attach it to the pilot measurements so the decision can be revisited on evidence rather than re-argued from scratch. The reason to insist on that ceremony is the failure mode. A missing execution rule does not fail loudly on the day it is refused. It fails months later, quietly, when there is an intrusion and nothing to reconstruct it from — and by then nobody remembers whose call it was.