Documentation / Engineering
Architecture
Interface, engine, privileged service, Windows.
GURDN is four layers. The important property is where privilege begins, which is as late as possible and in as small a component as the work allows.
Figure 2, trust boundary
Desktop interface
Shows state, asks for authorisation. Holds no privilege.
Security engine
Observation, baseline, detection, trust, policy, response. Decides; cannot act.
Privileged Windows service
The few operations that need privilege, and nothing else.
Windows
Owns the configuration.
The layers
Shows what was observed, what was decided and what is proposed. Asks for authorisation. It holds no privilege and performs no operation itself.
Tauri and React. Privilege: none.
Observation, baselines, diffing, correlation, detection rules, trust, policy and the response lifecycle. It decides; it does not have the rights to act.
Rust. Privilege: none.
The small set of operations that genuinely require privilege: firewall filters, resolver configuration, and the checks those need. Reached only across a restricted local endpoint.
Windows service, own restricted identity. Privilege: elevated, narrowly.
Owns the configuration. GURDN uses the interfaces Windows provides and reports that a capability is unsupported where it provides none.
Filtering Platform, IP Helper, firewall policy store. Privilege: the platform.
Why the service exists
Changing a firewall profile, installing a filter or setting a resolver all require rights an ordinary application does not have. There are two ways to get them. One is to run the whole product elevated, which means the interface, the rendering engine and every dependency they pull in are running with the rights to reconfigure the machine. The other is to put the few operations that need privilege behind a boundary, and run everything else without it.
GURDN takes the second. The service runs under its own restricted service identity rather than as the local system account with everything available to it, and it performs a defined set of operations rather than accepting commands.
Why the interface is not trusted
The desktop interface is the largest and most exposed part of the product: it renders content, handles input, and carries the most third-party code. Treating it as untrusted is what stops a flaw there from becoming a flaw in your network configuration. It asks the engine; the engine asks the service; the service checks the request itself rather than trusting that someone upstream already did.
The boundary
One restricted local endpoint, described in the security model. It rejects remote clients, is restricted to the system account and administrators, claims its name in a way that fails if something already holds it, and refuses an oversized message before allocating memory for it.
Dependencies point one way
The crate graph enforces the direction: the interface cannot reach the platform layer, the trust engine knows nothing about any specific carrier or vendor, and no engine knows about the shell. Only one crate calls Windows APIs for observation, and it is read only.