Post

Replies

Boosts

Views

Activity

Does SessionGetInfo provide authoritative current-session liveness for an ASID from a Mach audit token?
Environment: macOS 26.6.2 (25G83) Xcode 26.6 (17F113) macOS command-line process Security.framework SessionGetInfo ASID obtained from the kernel-provided audit token in a received Mach message I’m implementing a security-sensitive Mach IPC receiver. The receiver obtains the sender’s audit token from the Mach message trailer and derives the sender PID, effective UID, and audit session ID (ASID). The sender executable identity is validated separately. Given the ASID, SessionGetInfo can successfully return the corresponding SecuritySessionId and session attributes. The question is about the freshness and synchronization semantics of that lookup. At the point where the receiver authorizes a request, can a successful SessionGetInfo(asid, ...) result be treated as authoritative evidence that the corresponding login/audit session is still currently valid? In particular: What happens if the session logs out, terminates, or is revoked concurrently with the lookup? Can SessionGetInfo successfully return information for a session that is no longer current due to caching or propagation delay? Are there documented ordering or synchronization guarantees between session termination and subsequent SessionGetInfo calls from another process? Can the lookup block for an unbounded period if the underlying security service is unavailable? Is there a supported timeout or cancellation mechanism? Is there another supported public macOS API better suited to establishing authoritative current-session liveness for an ASID obtained from an audit token? The security requirement is fail-closed. I’m specifically trying to avoid private APIs, process-table heuristics, diagnostic launchctl output, or assumptions that the ASID encoded in a previously received audit token necessarily represents current session state. If the public API does not provide an authoritative liveness/freshness guarantee, confirmation of that limitation would also answer the design question. I also have a minimal 122-line Xcode sample that: creates and receives a Mach message, reads the kernel-provided audit trailer, extracts the ASID, calls SessionGetInfo, and prints the returned session ID and attributes. I can provide the sample project if useful.
8
0
310
13h
Does SessionGetInfo provide authoritative current-session liveness for an ASID from a Mach audit token?
Environment: macOS 26.6.2 (25G83) Xcode 26.6 (17F113) macOS command-line process Security.framework SessionGetInfo ASID obtained from the kernel-provided audit token in a received Mach message I’m implementing a security-sensitive Mach IPC receiver. The receiver obtains the sender’s audit token from the Mach message trailer and derives the sender PID, effective UID, and audit session ID (ASID). The sender executable identity is validated separately. Given the ASID, SessionGetInfo can successfully return the corresponding SecuritySessionId and session attributes. The question is about the freshness and synchronization semantics of that lookup. At the point where the receiver authorizes a request, can a successful SessionGetInfo(asid, ...) result be treated as authoritative evidence that the corresponding login/audit session is still currently valid? In particular: What happens if the session logs out, terminates, or is revoked concurrently with the lookup? Can SessionGetInfo successfully return information for a session that is no longer current due to caching or propagation delay? Are there documented ordering or synchronization guarantees between session termination and subsequent SessionGetInfo calls from another process? Can the lookup block for an unbounded period if the underlying security service is unavailable? Is there a supported timeout or cancellation mechanism? Is there another supported public macOS API better suited to establishing authoritative current-session liveness for an ASID obtained from an audit token? The security requirement is fail-closed. I’m specifically trying to avoid private APIs, process-table heuristics, diagnostic launchctl output, or assumptions that the ASID encoded in a previously received audit token necessarily represents current session state. If the public API does not provide an authoritative liveness/freshness guarantee, confirmation of that limitation would also answer the design question. I also have a minimal 122-line Xcode sample that: creates and receives a Mach message, reads the kernel-provided audit trailer, extracts the ASID, calls SessionGetInfo, and prints the returned session ID and attributes. I can provide the sample project if useful.
Replies
8
Boosts
0
Views
310
Activity
13h