> For the complete documentation index, see [llms.txt](https://docs.linuxguard.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.linuxguard.io/concepts/concepts/console/audit.md).

# Audit

The Audit pillar reconciles what was authorized against what actually executed across the fleet. It answers two related questions: "what privileged actions did our policies and rules permit?" and "what privileged actions actually ran, by whom, and were they within scope?" Audit is used by security analysts producing privilege-review evidence, compliance auditors validating that least-privilege controls are working, and incident responders reconstructing the path a privileged action took through the system.

> **Note**: The LinuxGuard Console is the canonical reference for screen-by-screen layout. This page describes the conceptual scope and integration points.

Audit is distinct from the tenant-level Audit Logs surface (under Compliance & Audit). Audit Logs record actions taken inside the LinuxGuard console — administrator activity in the UI. The Audit pillar records actions taken on monitored servers — authorizations granted and privileged commands executed at the OS level. Both surfaces are evidence-grade; they answer different questions.

## Authorizations audit

Authorizations audit catalogues the privilege grants that exist across the fleet and produces an evidence record of what is currently authorized to run as a privileged user. The view consolidates four input sources:

* **SUDO rule grants** — `user / group ALL = (runas) command` rules from sudoers and sudoers.d, expanded to enumerate the full set of (identity, command) pairs the rule authorizes
* **Group memberships in privileged groups** — accounts in `wheel`, `sudo`, `adm`, `docker`, and tenant-configured sensitive groups
* **PAM policy outcomes** — which authentication methods are enabled for elevation (password, key, hardware token)
* **SELinux role / type bindings** — where SELinux is in enforcing mode, the SELinux roles each user can transition into

The authorizations audit table answers questions like: "Which accounts can run `systemctl restart deploy-svc` as root, across the entire fleet?" or "Show every account with sudo access to any file-system-modifying command on production servers." It is the evidence record an auditor or reviewer consumes when asked to demonstrate that privilege scope is bounded.

Each authorization row carries provenance — which file granted the privilege, which line, which group membership, and which baseline (if any) the authorization is part of. Provenance is what lets an operator answer the follow-up "and where does that grant come from?" without leaving the view.

A common use of authorizations audit is the quarterly access review: export the table, route per-server slices to the owning team, and require sign-off that each row remains appropriate. Privilege grants that no team will own are removal candidates.

## SUDO execution audit

SUDO execution audit records what privileged commands actually ran on each monitored server, with full identity attribution. Each execution event captures:

| Field              | Source                                                                                                                    |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| Invoker username   | Process credentials at exec time                                                                                          |
| LoginUID           | Linux Audit loginuid (survives sudo escalation; identifies the original logged-in user even when commands run via `sudo`) |
| Effective UID      | Final UID under which the command executed                                                                                |
| Command            | Full command line (`argv`)                                                                                                |
| Target host        | Server hostname                                                                                                           |
| Timestamp          | UTC, agent-side                                                                                                           |
| Authorization path | Which SUDO rule, group membership, or PAM policy granted the execution                                                    |

The LoginUID is load-bearing. It is the identifier that survives sudo escalation — when a developer logs in as `alice`, runs `sudo -i`, becomes `root`, and then runs `systemctl restart`, the effective UID at exec time is 0 (`root`) but the LoginUID remains `alice`'s. Without LoginUID correlation, every sudo command appears to have been run by `root`, which destroys the audit trail. With it, every command remains traceable to the human who authorized it.

Execution events surface the **authorization path** that permitted the command. This is the reconciliation between the authorizations audit (what was permitted) and the executions audit (what ran): every executed command should map to a permitted authorization. Commands that executed but do not map to any current authorization — typically a result of an authorization that was revoked after the command ran, or a misattribution case — surface as reconciliation gaps for review.

The audit feed supports filtering by invoker, LoginUID, server, command pattern, time window, and authorization path. CSV and JSON export are available for evidence packages.

## Data sources

The Audit pillar draws on agent telemetry collected at the kernel level. Authorization data comes from the same baseline / config-file inputs used by Baselines (sudoers, group membership, PAM, SELinux). Execution data comes from kernel-level process / audit framework integration:

| Data                  | Agent surface                                                                                                           |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Authorization grants  | `/etc/sudoers`, `/etc/sudoers.d/*`, `/etc/group`, `/etc/pam.d/*`, `getsebool` / `semodule -l` where SELinux is enforced |
| LoginUID correlation  | Linux Audit subsystem (`/proc/[pid]/loginuid`) and eBPF process tracing                                                 |
| Command execution     | eBPF tracing of `execve` syscalls; Linux Audit rules where eBPF is unavailable                                          |
| Effective credentials | Kernel process credentials at exec time                                                                                 |

LoginUID correlation requires the Linux Audit subsystem to be enabled on monitored servers (`auditd` running) or the agent's eBPF-based loginuid tracing to be functional. On servers in `DegradedNoEBPFArch` mode (per the multi-arch architecture matrix), LoginUID correlation falls back to auditd-only and may be unavailable if auditd is also disabled.

## Module gating

The Audit pillar is part of the Zero Trust module. Authorizations audit and SUDO execution audit are available together. Subscription gating documented in console — historical retention windows for execution events and CSV / JSON export cadence may vary by tier.

## Cross-references

* Related CLI commands: [`config`](/reference/reference/cli/config.md) (audit-related collection toggles), [`probe`](/reference/reference/cli/probe.md) (verifies audit / eBPF execve probes are healthy)
* Related Concepts: [Zero Trust Enforcement](/concepts/concepts/console/zero-trust-enforcement.md) (SUDO Policies analysis), [Zero Trust Expansion](/concepts/concepts/console/zero-trust-expansion.md) (SUDO executions surface and policy violations), [Baselines](/concepts/concepts/console/baselines.md) (SUDO rules / aliases / defaults baselines), [Compliance Expansion](/concepts/concepts/console/compliance-expansion.md) (audit evidence in compliance reporting)
* Related How-to: [Configure](/configure/configure.md) (enabling Linux Audit integration)

***

**Related**: [Console](/concepts/concepts/console.md) | [Zero Trust Enforcement](/concepts/concepts/console/zero-trust-enforcement.md) | [Zero Trust Expansion](/concepts/concepts/console/zero-trust-expansion.md) | [Baselines](/concepts/concepts/console/baselines.md) | [Glossary](/reference/reference/glossary.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.linuxguard.io/concepts/concepts/console/audit.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.