← Back to All Writeups

Deterministic Edge Architecture: Isolation Diagrams and Least Privilege

Most contemporary web breaches do not stem from sophisticated cryptographic flaws, but from the inherent fragility of dynamic execution layers: outdated CMS plugins, insecure backend deserialization, SQL injection, and over-privileged server daemons.

In this writeup, we examine the deterministic architectural model behind valmis.net, engineered to reduce attack surface to zero through static content immutability served by native UNIX daemons.


1. Architectural Flow Diagram

The publishing pipeline strictly isolates the authoring/compilation phase on the local developer workstation from the static serving phase on the edge OpenBSD host:

+-------------------------------------------------------------------------------+
|                       PHASE 1: AUTHORING & COMPILATION (LOCAL)                |
+-------------------------------------------------------------------------------+
|  +---------------------+        +--------------------+        +-------------+ |
|  | Markdown in VIM     |  --->  |  Go SSG Builder    |  --->  | Output      | |
|  | (content/posts/*.md)|        |  (goldmark parser) |        | public/*.html|
|  +---------------------+        +--------------------+        +-------------+ |
+-------------------------------------------------------------------------------+
                                         |
                                         | Secure Synchronization (rsync / SSH)
                                         v
+-------------------------------------------------------------------------------+
|                   PHASE 2: STATIC SERVING EDGE (OpenBSD)                      |
+-------------------------------------------------------------------------------+
|                                                                               |
|      [ WAN / Public HTTPS:443 Traffic ]                                       |
|                       |                                                       |
|                       v                                                       |
|         +---------------------------+                                         |
|         |     PF (Packet Filter)    |                                         |
|         |  - Stateful inspection    |                                         |
|         |  - Rate-limit synproxy    |                                         |
|         +---------------------------+                                         |
|                       |                                                       |
|                       v                                                       |
|         +---------------------------+                                         |
|         |    OpenBSD httpd(8)       | <--- Chrooted in /var/www               |
|         |    (Native Web Server)    | <--- pledge("stdio rpath inet")         |
|         +---------------------------+ <--- unveil("/htdocs/valmis.net", "r")  |
|                       |                                                       |
|                       v                                                       |
|         +---------------------------+                                         |
|         |   /htdocs/valmis.net/     | (Static HTML5, pure CSS & images)       |
|         +---------------------------+                                         |
|                                                                               |
+-------------------------------------------------------------------------------+

2. Threat Vector Mitigation Matrix

Replacing dynamic runtimes (PHP, Node.js, Python WSGI) with pre-rendered pages served by httpd(8) eliminates entire classes of vulnerabilities:

Attack Vector Traditional Dynamic Stack valmis.net Static Architecture
SQL Injection (SQLi) High risk (RDBMS dependency) Non-existent (Zero database)
Remote Code Execution (RCE) Vulnerable via plugins / deserialization Non-existent (Zero runtime interpreters)
Cross-Site Scripting (XSS) Requires continuous input sanitization Neutralized (CSP: script-src 'none')
Privilege Escalation Web processes holding shell/file handles Mitigated by chroot + pledge(2) + unveil(2)
Denial of Service (DoS) Expensive DB queries exhaust CPU Resilient (PF synproxy + in-memory files)

3. OpenBSD Kernel Isolation Mechanisms

The httpd(8) daemon operates in a multi-layered sandbox enforced by the operating system kernel:

chroot(2) in /var/www

The daemon has zero visibility of /etc, /root, /usr, or system binaries. Its root directory is strictly locked to /var/www.

pledge(2): “stdio rpath inet”

Once initialized and listening on ports, httpd renounces all system calls except the absolute minimum required to read files and reply to network streams.

unveil(2): File System Restriction

Even within the chroot jail, httpd can only read ("r") from /htdocs/valmis.net. Access outside this directory instantly fails.


4. Latency & Performance Benchmarks

With no database lookups or runtime template rendering, response latency is bounded only by the physical speed of the network:

Benchmark: 10,000 concurrent requests to valmis.net
--------------------------------------------------------------
Time taken for tests:   0.312 seconds
Complete requests:      10,000
Failed requests:        0
Requests per second:    32,051.28 [#/sec] (mean)
Time per request:       0.031 [ms] (mean, across all concurrent requests)
HTML Transfer size:     ~5.4 KB (Optimized HTML5)

Summary

True resilience is not achieved by bolting intrusion detection systems on top of defective code, but by designing architectures with an intrinsically zero attack surface.