Audit

Audit pillar in the LinuxGuard console — authorizations audit and SUDO execution audit for privileged-action reconciliation.

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 (audit-related collection toggles), probe (verifies audit / eBPF execve probes are healthy)

• Related Concepts: Zero Trust Enforcement (SUDO Policies analysis), Zero Trust Expansion (SUDO executions surface and policy violations), Baselines (SUDO rules / aliases / defaults baselines), Compliance Expansion (audit evidence in compliance reporting)

• Related How-to: Configure (enabling Linux Audit integration)

---

Related: Console | Zero Trust Enforcement | Zero Trust Expansion | Baselines | Glossary