3.7 kacs.caap.staging.diverged

  • Event type: kacs.caap.staging.diverged
  • Defined in: kacs.evman
  • Tier: standard
  • Gating: a staged central access policy applies to the object, and its result differs from the effective one
  • Cardinality: once per access check

The record that a staged central access policy would have decided an access differently from the policy in force. The access itself is decided by the effective policy alone; this records what promoting the staged one would change, for this subject and this object.

It is the event to watch while trialling a policy: stage it, let the system run, and read these records to see who would gain or lose access before anyone does. It is silent unless a staged policy exists, so on most systems it never fires.

The difference is not always in the grant. Staged and effective evaluation also differ when the per-object results of an object-type check differ, or when the audit records the two would produce differ, so a record can carry equal access.granted and access.granted-staged.

3.7.1 Fields #

FieldTypePresenceMeaning
subject.token.sidbin.sidvia subjectThe user SID of the effective token the operation ran under.
subject.token.groupsbin.sid[]via subjectThe group SIDs carried by the effective token.
subject.token.group-attributesuint.flags[]via subjectPer-group attribute bitmasks, positionally parallel to subject.token.groups.
subject.token.integrityuint.integrityvia subjectThe integrity RID of the effective token.
subject.token.iduint.luidvia subjectThe token's own LUID, identifying this specific token rather than the logon session it belongs to.
subject.token.auth-iduint.luidvia subjectThe LUID of the logon session the effective token belongs to.
subject.token.typestr.enumvia subjectWhether the effective token is a primary token or an impersonation token.
subject.token.impersonationuint.enumvia subjectThe impersonation level of the effective token.
subject.token.uiduintvia subjectThe Linux UID this token projects onto, for correlating a Peios event with Linux-side audit data.
emitter.process.piduintvia subjectThe process ID the record was written from.
emitter.process.namestrvia subjectThe kernel's name for the emitting process, typically the executable's basename.
emitter.process.executablestr.pathvia subjectThe path the emitting process was executed from, resolved at exec with symbolic links already followed.
subject.pip.typeuint.enumvia subjectThe Protected Isolated Process type in force for the access check.
subject.pip.trustuintvia subjectThe PIP trust level in force for the access check.
object.kindstr.enumrequiredWhat sort of thing the operation acted on.
object.file.pathstr.pathwhen object.kind == fileThe absolute path of the file the operation acted on, resolved at the enforcement point.
object.process.piduintwhen object.kind == processThe process ID of the process the operation acted on.
object.process.guidbin.guidwhen object.kind == processThe durable GUID of the process the operation acted on.
object.token.iduint.luidwhen object.kind == tokenThe LUID of the token the operation acted on, for token-open and token-adjust checks.
object.token.guidbin.guidwhen object.kind == tokenThe durable GUID of the token the operation acted on.
access.requesteduint.maskrequiredThe access mask the caller asked for, after generic bits have been mapped to type-specific ones.
access.granteduint.maskrequiredWhat the effective policy granted: the access the caller actually got.
access.granted-stageduint.maskrequiredWhat the staged policy would have granted instead.
fields.attestation.userspacebooloptionalSet on every record of the AccessCheck syscall, and on no other. There the descriptor, and with it trigger.ace, is always the caller's, as are any audit context and PIP state it passes.

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

Edit this page