Auditing in AccessCheck

Auditing is purely observational. No audit rule affects the access decision. Audit ACEs are evaluated after the access decision is final.

KACS defines three auditing mechanisms within the AccessCheck pipeline.

For AccessCheck-emitted KMES records, KACS uses two event families:

• access-audit for object-access audit events emitted from the SACL walk and token audit-policy forcing
• privilege-use for privilege-use audit events

The exact event type strings and msgpack payload schemas are defined in Appendix A: Audit Event Schemas.

§10.9.1 Access auditing #

SYSTEM_AUDIT ACEs in the SACL define which access attempts to log. Each audit ACE specifies:

• A SID — matched using deny polarity (the broadest identity view -- deny-only groups are visible). Auditing SHOULD capture the widest possible picture.
• An access mask — which operations are audited.
• Success and/or failure flags — SUCCESSFUL_ACCESS_ACE_FLAG (0x40) and FAILED_ACCESS_ACE_FLAG (0x80) control whether to audit successful access, failed access, or both.

When an audit ACE's SID matches the caller, its mask overlaps with the generic-mapped requested access mask, and its success/failure flags match the final outcome, an audit event is emitted.

The overlap check uses the mapped requested mask after generic mapping (mapped_desired in the algorithm), not the final granted mask. This ensures failed requests are still auditable for the rights that were actually requested.

Conditional audit ACEs carry expressions that gate whether the event fires. Conditional audit ACE expressions use deny-side membership polarity for Member_of and related operators, matching the SID-match rule above. An expression that evaluates to UNKNOWN results in the event being emitted (when in doubt, audit).

§10.9.2 Continuous auditing #

Access auditing fires once, at the point where AccessCheck runs. Continuous auditing fills the gap for per-operation monitoring.

SYSTEM_ALARM ACEs configure per-operation audit masks. When AccessCheck evaluates an alarm ACE and the caller's SID matches, the ACE's access mask is recorded as a continuous audit mask on the open handle. Conditional alarm ACE expressions use the same deny-side membership polarity as conditional audit ACE expressions. On each subsequent operation, the enforcement point checks the handle's continuous audit mask and emits a continuous-audit event when the operation's normalized required-access mask overlaps the stored continuous audit mask.

The continuous audit mask is returned by AccessCheck to the caller (FACS, registryd), which stores it on the handle and enforces it per-operation.

For FACS file handles, the normalized required-access mask is the same mask used by the use-time handle check in facs/use-time.md. For operations whose authorization accepts one of several rights, such as append-or-write data, the required-access mask contains the accepted right set and the event records the subset that overlapped the continuous audit mask.

Continuous-audit events are emitted after the per-operation decision is known. Successful and denied attempts are both emitted when the attempted required-access mask overlaps the handle's continuous audit mask. The event subject and process are the operation-time current effective token and current task, not necessarily the token or process that originally opened the handle. This preserves correct attribution after handle transfer while still using the opener-computed handle mask to decide whether the handle is continuously audited.

If an enforcement point cannot construct a required continuous-audit event, it MUST fail closed. KMES transport buffering and drop accounting remain KMES behavior.

§10.9.3 Privilege-use auditing #

When a privilege is exercised to grant access that the DACL would not have independently granted, a privilege-use audit event MAY be emitted. This fires after the complete evaluation pipeline -- after integrity policy, confinement, and central access policy.

KACS distinguishes success and failure privilege-use auditing:

• Successful privilege use — the privilege contributed requested bits that survive to the final granted result. In this case the privilege is marked used, and a privilege-use audit event is emitted when audit_policy & PRIVILEGE_USE_SUCCESS (0x04).
• Failed privilege use — the privilege contributed requested bits during evaluation, but those bits do not survive to the final granted result. In this case the privilege is not marked used, and a privilege-use audit event is emitted when audit_policy & PRIVILEGE_USE_FAILURE (0x08).

If a privilege did not contribute to the requested access at all, no privilege-use audit event is emitted.

§10.9.4 Per-token audit policy (algorithm step 14b) #

The token's audit_policy field MAY force audit events for specific categories regardless of SACL content. This runs after the SACL walk (step 14) and before result computation (step 15). The kernel checks:

• If the access succeeded and audit_policy & OBJECT_ACCESS_SUCCESS (0x01): emit a success audit event.
• If the access failed and audit_policy & OBJECT_ACCESS_FAILURE (0x02): emit a failure audit event.

These events are additive — they fire even if no SACL ACE matched. The object_audit_context from the AccessCheck caller is included in the event. Token audit policy is per-token, set at creation time, and follows impersonation (the impersonated token's policy applies during impersonation).

§10.9.5 Audit event contents #

Each audit event contains:

• Subject — the calling token's identity (user SID, group SIDs, integrity level, PIP identity).
• Object — caller-provided context identifying the object.
• Access — what was requested, what was granted, whether the request succeeded or failed.
• Trigger — which audit ACE matched, or which privilege was exercised.
• Process — the calling process's PID, name, and executable path.