Investigate privilege-auth signal boundaries against current detector contracts

[stacknil]

Context / observed surface

LogLens currently has separate parser, normalized event, authentication signal, detector, and report surfaces for Linux authentication evidence. This issue asks for a bounded audit of how three privilege-adjacent record families travel through those existing layers:

• a sudo authentication/password failure;
• a sudo policy or sudoers denial;
• a failed su authentication record.

Use a small sanitized or synthetic fixture set and trace the current path on main:

parser -> Event / EventType -> AuthSignal mapping -> existing detector eligibility -> Finding / report artifact behavior

Relevant starting points include:

• src/parser/sudo_handlers.cpp and src/parser/su_handlers.cpp
• src/event.hpp, src/signal.hpp, and src/signal.cpp
• src/detector.cpp and src/report.cpp
• docs/parser-conformance-matrix.md, docs/rule-catalog.md, and docs/report-artifacts.md
• focused evidence in tests/test_parser.cpp, tests/test_detector.cpp, and checked-in sanitized artifacts

The purpose is to verify the current contract, not to propose broader privilege detection.

Diagnostic question

For each case, determine whether the current treatment is:

A. consistent with the documented detector contract;
B. a documentation or observability ambiguity; or
C. an actual semantic defect.

Preserve uncertainty when the repository evidence is insufficient. Do not assume that every parsed record should become detector evidence or a finding.

Please include a compact evidence matrix:

Case	Parsed?	Normalized EventType / signal	Existing rule eligibility	Current finding/report surface	Contract evidence
sudo authentication/password failure
sudo policy or sudoers denial
failed su authentication

Evidence required

Answer these questions with exact code, test, fixture, documentation, or generated-artifact references:

• Which existing contract or invariant governs each case?
• What does the current implementation actually do at every relevant layer?
• Is that behavior consistent with the current documentation?
• What behavior must remain unchanged?
• What evidence, if any, makes a repository change necessary?

Include the input mode, configuration, and reproduction commands used. Distinguish normalized events, signal eligibility, findings, parser warnings, and report visibility rather than treating them as one outcome.

Change threshold

Post the investigation evidence and classification in this issue before opening a PR.

A code or documentation PR is justified only if the investigation identifies a concrete contract contradiction, a missing reviewer-visible surface, or a reproducible ambiguity. If a behavioral regression is claimed and a PR later follows, include a focused red -> green regression where practical: the test should fail against the relevant base behavior and pass after the proposed fix.

Do not prescribe an implementation from the issue evidence alone.

Behavior that must remain unchanged

State explicitly which neighboring parser, signal, detector, warning, finding, and report contracts are outside any proposed correction. In particular, explain how a narrowly justified change would avoid altering unrelated authentication evidence or existing rule semantics.

Boundaries

• No detector promotion is requested.
• No new finding or rule is assumed necessary.
• No incident verdict, compromise attribution, or session-causality claim.
• No real authentication logs, usernames, addresses, host identifiers, credentials, screenshots, or private paths.
• No offensive credential-testing workflow.
• Use only sanitized or synthetic repository evidence.
• Keep this separate from the future design questions in Backlog: decide configurable semantics for privilege auth failure signals #100, Backlog: defer login-to-privilege session causality correlation #101, and Backlog: evaluate report surface for non-counting auth signals #102.