Security model

GURDN asks for privilege, so what it does with that privilege is the part worth examining. This page is written for a reader who intends to check.

Threat model, briefly

GURDN is designed to be useful against an adversary who can influence the connectivity environment of a machine: a hostile or compromised network, a captive portal, a device on the same segment, or software that changes network configuration without the user understanding what changed.

It is not designed to defend a machine whose operating system is already under an attacker's control. An adversary with administrative rights can stop the service, alter the stored record and lie to the product. GURDN can make that detectable; it cannot make it impossible, and it does not claim to.

Privilege separation

The interface and the engine hold no privilege. A separate Windows service, running under its own restricted service identity, performs the operations that need it. See architecture.

The IPC contract

• Local only. The endpoint rejects remote clients. A request can only originate on the machine itself.
• Restricted callers. The access control list names the system account and administrators. A process belonging to another user cannot connect.
• First instance only. The service claims the endpoint in a way that fails if something already holds that name, rather than quietly sharing it with whatever got there first.
• Bounded messages. A message larger than the fixed limit is refused before any memory is allocated for it, so an oversized request cannot be used to exhaust the service.
• An allowlist of operations. The service accepts a defined set of operations with validated parameters. It does not take arbitrary commands, and it invokes no processes and loads no libraries by name, which is enforced by a scan over the crate rather than by review alone.
• Expiry and replay rejection. A request carries a validity window. An expired request is refused, and a previously seen request cannot be replayed to cause a second change.

Ownership

Firewall filters are registered under a provider belonging to GURDN, so the platform itself distinguishes them. GURDN removes only its own. This is a property Windows enforces, not a convention GURDN follows.

The same principle governs uninstallation: where ownership of something cannot be established, destructive cleanup is refused rather than forced. There is no override flag for this, deliberately.

Verification and rollback

Every change is confirmed by reading the machine back, and every step records its undo before it runs. See verification and recovery.

Audit integrity

Each record entry's digest covers the previous entry's digest. An edited or deleted entry breaks the chain, and GURDN reports the first entry that does not verify rather than declaring the whole record untrustworthy. This detects tampering; it does not prevent it.

Installation

Installation runs as a transaction in which every step records how to undo itself. Service registration, directory permissions and the endpoint are each confirmed by reading the machine. A failure walks the completed steps back. Elevation is checked first, so an unelevated attempt is a clear refusal rather than a partial install, and every refusal carries a specific exit code rather than a general failure.

Updates

Covered in full on updates: signature, payload digest, key standing, downgrade rejection, manifest expiry and staging containment.