diff --git a/.agents/skills/libreqos_security_audit/SKILL.md b/.agents/skills/libreqos_security_audit/SKILL.md index a1fd0a74..3261d7b9 100644 --- a/.agents/skills/libreqos_security_audit/SKILL.md +++ b/.agents/skills/libreqos_security_audit/SKILL.md @@ -1,6 +1,6 @@ --- name: libreqos_security_audit -description: Repo-local LibreQoS workflow for release security audit passes. Use when auditing LibreQoS with cargo audit, cargo machete, cargo tree, CVE triage, network control-plane exposure review, bridged-interface/eBPF malformed-traffic review, panic/error-handling/type-loss review, node_manager privacy/auth/XSS review, and audit-file findings updates. +description: Repo-local LibreQoS workflow for release security audit passes. Use when auditing LibreQoS with cargo audit, cargo machete, cargo tree, CVE triage, network control-plane exposure review, bridged-interface/eBPF malformed-traffic review, panic/error-handling/type-loss review, node_manager privacy/auth/XSS review, executive-summary/conclusion grading, and audit-file findings updates. --- # LibreQoS Security Audit @@ -8,8 +8,9 @@ description: Repo-local LibreQoS workflow for release security audit passes. Use Use this skill for recurring LibreQoS security audit passes in this repo. It covers the Rust dependency baseline, network control-plane exposure review, bridged-interface/eBPF malformed-traffic review, and panic/error-handling/type -loss review, and node_manager privacy/auth/XSS review. Use additional focused -checks for Python, packaging, live-host configuration, secrets, and +loss review, node_manager privacy/auth/XSS review, and final executive-summary +wrap-up. Use additional focused checks for Python, packaging, live-host +configuration, secrets, and authentication flows outside these scopes. ## Scope @@ -406,6 +407,50 @@ The audit-file section must include: localStorage token is found. - No placeholders, no `...`, and no unresolved `` tokens. +## Step 6: Audit Introduction, Executive Summary, Conclusion, and Grade + +Use this step after the requested audit sections have enough findings to +summarize. Keep the write-up brief enough for release planning while preserving +the concrete evidence in the detailed sections below. + +At the beginning of the audit file, add: + +- `Introduction`: the audit date, overall scope, what was static-only, and major + exclusions such as Linux/Ubuntu vulnerabilities, live firewall state, or + deployment-specific controls not visible in the checkout. +- `Executive summary`: bullet points that signal the actionable issues found + later in the document. Include the highest-risk findings, non-findings that + matter to release confidence, and the recommended fix priority. +- An overall letter grade from `A` to `F`. Use the grade as a concise release + posture signal, not as a substitute for findings. + +At the end of the audit file, add: + +- `Conclusion`: restate the overall grade and explain the security posture in a + balanced way. +- Call out what LibreQoS is doing right, such as dependency health, auth layers, + TLS/Caddy direction, redaction of secrets, verifier-conscious eBPF bounds + checks, or any other strengths actually found in the detailed sections. +- Call out what needs work, prioritizing concrete risk over volume of findings. +- Keep recommendations aligned with the detailed findings. Do not introduce new + unsupported claims in the conclusion. + +Suggested grading rubric: + +- `A`: No confirmed high-impact release issues, strong auth/session boundaries, + validated input handling, and only minor hardening items remain. +- `B`: Good foundations with a few bounded, actionable hardening issues. +- `C`: Acceptable foundations, but multiple actionable issues remain in + control-plane, WebUI, privacy, panic/DoS, or observability paths. +- `D`: Security-critical issues are likely reachable or broad auth/privacy + boundaries are missing. +- `F`: Known unauthenticated compromise, widespread secret exposure, or a + release-blocking vulnerability with no mitigation. + +The introduction, executive summary, and conclusion must not contain +placeholders, speculative certainty, or findings that are absent from the body of +the audit. + ## Validation - Re-read the audit section before returning; remove placeholders and vague conclusions. diff --git a/SECURITY_AUDIT_2026_05_15.md b/SECURITY_AUDIT_2026_05_15.md index 19f947db..7382c755 100644 --- a/SECURITY_AUDIT_2026_05_15.md +++ b/SECURITY_AUDIT_2026_05_15.md @@ -1,3 +1,44 @@ +## Introduction + +This audit is a basic pre-release security review of LibreQoS as of +2026-05-15. It focuses on dependency advisories, Rust dependency hygiene, +control-plane exposure, bridged-interface and eBPF malformed-traffic handling, +panic/error/type-loss paths, and Node Manager privacy, authentication, and XSS +risk. + +The review is static unless a section explicitly says otherwise. It does not +cover Ubuntu/Linux distribution vulnerabilities, live firewall state, NIC driver +behavior, or private deployment-specific controls that are not visible in this +checkout. + +## Executive summary + +- Overall grade: **C**. LibreQoS has several strong security foundations, but + the current release state includes multiple actionable control-plane and WebUI + issues that should be fixed or explicitly risk-accepted before release. +- No CVE-class Rust dependency vulnerability was confirmed as reachable during + the dependency audit. A `rand` soundness advisory remains reachability unknown, + and one likely unused dependency should be removed. +- The Caddy/TLS path is generally well-directed for the WebUI, but the sibling + API service can still bind directly on all interfaces, malformed bearer headers + can panic API authentication, WebUI/local API CORS is too broad, and WebUI + login lacks rate limiting. +- The eBPF packet parsers show good verifier-conscious bounds checking for + common encapsulation paths, but malformed traffic can still create operational + DoS or visibility loss through packet-rate debug logging, IPv4 fragment/header + edge cases, and non-LRU map exhaustion. +- The panic/type-loss review found request-time panic paths and unchecked numeric + narrowing that can lose operational data in queue stats and NetFlow export. +- Node Manager has the highest concentration of release-relevant WebUI risk: + anonymous/read-only paths can retrieve raw subscriber and topology data, + operator-controlled strings reach `innerHTML`, the session cookie is readable + by JavaScript, and read-only users can write dashboard themes that can become + stored XSS. +- Recommended release priority is to first fix WebUI XSS/session-cookie exposure, + server-side anonymization for anonymous/demo mode, API direct-listener/TLS + bypass risk, malformed auth-header panic, and production packet-path debug + logging. + ## Rust dependency audit Date: 2026-05-15 @@ -1003,3 +1044,31 @@ Recommended actions: credentials there, but interface names, VLANs, and operation IDs are operationally sensitive on shared browsers. Prefer `sessionStorage` or clear these keys on logout, confirm, and rollback. + +## Conclusion + +Overall security grade: **C**. + +LibreQoS is not starting from a bad place. The review found no confirmed +reachable CVE-class Rust dependency issue, the managed Caddy setup moves the +intended WebUI path toward loopback-backed TLS, Node Manager has a real +authentication/role model, eBPF packet parsing uses many explicit `data_end` +checks and bounded encapsulation loops, and several sensitive admin config values +are already redacted before they reach the browser. Those are meaningful +strengths, and they reduce the chance that the next release ships with a simple +dependency or parser-memory-safety failure. + +The weaknesses are concentrated around control-plane hardening and browser trust +boundaries. The biggest current risks are WebUI stored/DOM XSS, a JavaScript +readable session token, raw PII exposure in anonymous/read-only demo paths, an +API direct-listener path that can bypass the intended Caddy/TLS route if exposed, +request-time panics on malformed or stale inputs, and packet-path behavior that +can lose observability or consume CPU under malformed/high-cardinality bridged +traffic. + +The release posture should be: acceptable foundations, but not yet polished +security hygiene. Fixing the Node Manager XSS/session/anonymization issues and +the API/control-plane panic/listener issues would move the project materially +toward a **B**. Addressing the eBPF map-pressure/debug-logging findings, adding +rate limiting, and cleaning up numeric type-loss paths would make the security +state much more comfortable for routine release cadence.