GURDN

Security

GURDN asks for privilege, so here is what it does with it

A security application is a new component inside your trust boundary. This is the technical account of how that component is built, written for a reader who intends to check rather than to be reassured.

ValidationThe mechanisms below are implemented and covered by automated tests. Live validation on a clean, elevated Windows machine is part of release qualification and has not been completed. What is and is not verified.

01Threat model

What GURDN is for, and what it is not for

Stating this first makes everything after it checkable.

Designed against
An adversary who can influence the connectivity environment: 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.
Not designed against
A machine whose operating system is already under an attacker’s control. Someone with administrative rights can stop the service and alter the stored record. GURDN makes that detectable; it cannot make it impossible, and it does not claim to.
Out of scope entirely
Files, processes and malware, the contents of traffic, other devices on the network, and anything upstream of the machine such as a router, a provider or a carrier.

02Privilege

The interface has no privilege at all

The desktop application and the engine both run as the signed-in user. Only a separate Windows service holds the rights needed to change network configuration, under its own restricted service identity rather than as the local system account.

Figure 2, trust boundary

Tauri and React

Desktop interface

Shows state, asks for authorisation. Holds no privilege.

Rust

Security engine

Observation, baseline, detection, trust, policy, response. Decides; cannot act.

Own restricted service identity

Privileged Windows service

The few operations that need privilege, and nothing else.

Filtering Platform, IP Helper, firewall policy store

Windows

Owns the configuration.

The interface cannot reach Windows directly. Between the engine and the service is one restricted local endpoint, and only the service holds privilege.

03Boundary

One local endpoint, with a narrow door

The interface cannot ask Windows for anything. It sends a request across a single restricted channel, and the service validates what it receives rather than trusting the caller.

Local only
Remote clients are rejected. A request can only come from this machine.
Restricted callers
The access control list on the endpoint 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 exhaust the service.
An allowlist, not a command channel
A defined set of operations with validated parameters. The privileged crate invokes no processes and loads no libraries by name, which is enforced by a scan over the source rather than by review alone.
Expiry and replay rejection
Requests carry a validity window. An expired request is refused, and a previously seen one cannot be replayed to cause a second change.

04Changes

Owned, transactional, verified and reversible

Ownership by the platform
Firewall filters are registered under a provider belonging to GURDN, so Windows itself distinguishes them from everyone else’s. GURDN removes only its own, and that is enforced rather than conventional.
Applied as one unit
Filters are added inside a Windows Filtering Platform transaction. Either the whole set is present or none is, so an interruption cannot leave a partial policy.
Confirmed by reading back
Verified against the same source GURDN reports state from. A call that returned success without a matching read back is treated as a failure.
Reversible by design
Every step records its undo before it is attempted. Recovery walks them back in reverse and refuses to undo a step whose current state no longer matches.
Never silently reapplied
If a change is undone outside GURDN, it reports the mismatch rather than restoring something you did not re-authorise.

05Record

An audit trail that can be checked, not just read

Entries are chained, so removing or editing one is detectable. Verification names the first entry that does not match rather than condemning the whole record, which is the difference between a usable answer and an alarm.

Entries written before schema version 3 carry no chain digest and are skipped rather than reported as tampered. The record is local, bounded in size and age, and is intended to answer what GURDN did and when, not to serve as evidence to a third party.

06Updates

An update is verified before it is used, not after

The update path is one of the few places where a security product can become the attack.

Figure 4, update verification

Input

Update package arrives

  • Signature over the manifestor refuse
  • Payload digest matchesor refuse
  • Key standing is current or previousor refuse
  • Not a downgradeor refuse
  • Manifest is still in dateor refuse
  • Staging path stays inside its directoryor refuse
Result

Staged, and only then installable

Every check must pass before anything is written to disk. A build with no release key configured accepts nothing at all, which is deliberate.

A correct signature by a revoked key is still refused: revocation takes precedence over cryptographic validity. The full update documentation.

07Supply chain

How a build becomes something you could check

Reproducibility and signing are release properties, and the release gate treats them as mandatory rather than desirable.

Paths remapped
Builds remap source paths so an artefact does not carry the machine it was built on, and published artefacts are scanned to confirm they contain no repository path, user name or key material.
Deterministic bill of materials
Generated in a stable order, with no timestamp, and recorded against the commit.
Digests after signing
Signing rewrites the bytes, so the digests published for signed artefacts are generated after signing. Publishing a pre-signing hash beside a signed download is a mismatch a recipient cannot diagnose.
The gate can fail
The release gate is itself tested in both directions, so it refuses a build that should be refused and accepts one that should pass.