A security rule can hide an API contract
A Windows named-pipe contract forced one four-byte exception to a rule that required identity checks before protocol reads.
A security rule can smuggle one platform’s API order into policy. A port exposes that hidden contract when the new platform cannot obey the sequence.
Our Muniment Desktop record found this collision in a local, per-user endpoint. The smallest honest exception was four bytes, followed immediately by the original check.
Unix made the first rule look universal
On Unix, the listener accepts a connection and asks the kernel for the peer’s user identity. It compares that identity with its own.
The listener completes those steps before it reads one protocol byte. We wrote that order into an architecture decision record as a plain security rule.
The rule looked independent of its platform. Its order actually depended on the Unix API contract.
Windows required a read before the check
The Windows endpoint uses named pipes. Its server reads the connected client’s identity through ImpersonateNamedPipeClient.
Microsoft’s reference says the call adopts the security context of the last message read from the pipe. Microsoft does not state the byte-mode failure code there.
Our Muniment Desktop record supplies that result. On a byte-mode pipe, a server that has read nothing gets ERROR_CANNOT_IMPERSONATE.
The API therefore required a read before the identity check. Our written rule prohibited that read, which made its sequence impossible on Windows.
Microsoft is neither a Muniment customer nor an endorser. Its reference defines the last-message-read contract, while our record supplies the observed collision.
Two broad fixes gave away too much
The record considered three ways through the collision:
| Option | Effect | Decision |
|---|---|---|
| Switch the pipe to message mode | Forks wire framing for one platform | Reject |
| Read the whole first frame | Lets an unverified peer submit a parsed protocol message | Reject |
| Read the four-byte length prefix | Clears the API constraint before any frame body or response | Adopt |
Our frames start with a four-byte big-endian length prefix. The listener reads exactly that prefix, then runs the impersonation check.
Only a successful check permits the listener to read the frame body or write any byte. A rejected peer gets no protocol response.
The listener closes its handle instead. It treats a prefix above the frame-size limit the same way.
Four bytes carry no protocol authority
The prefix affects one bounds check. Nothing downstream treats it as protocol authority or branches on its contents for another purpose.
The endpoint also has a protected access-control list that grants access only to the creating user. Another operating-system user cannot open the pipe.
That access-control list remains the first defense. The identity check remains the second, with one named read before it.
We recorded the exception as a dated amendment instead of silently contradicting the old rule. The amendment permits only the four-byte prefix before the peer check.
It also repeats the closing rules for rejected peers and oversized prefixes. A future reader can find the reason beside the exceptional read.
The record leaves two security limits open
No integrated Windows session test exercises this order yet. The architecture decision record specifies the sequence without proving its implementation in a live session.
The record also claims no defense against a hostile process running as the same user. Same-user isolation sits outside this boundary.
We measured no performance effect. Visitors also cannot exercise Muniment Desktop through a public install or authentication surface yet.
This evidence comes from our Muniment Desktop note pinned to commit 6f6e78dc2e48389d04c8.
A cross-platform security rule needs an API-order audit. When contracts collide, name the collision and shrink the exception until the remaining rule still holds.
Sources
- Microsoft Learn: ImpersonateNamedPipeClient function learn.microsoft.com