P-01
Managed workloads are first-class objects.
A service, container, VM or agent receives a stable identity, declared resources, limits, policy and audit context.
Independent research fork · design phase
Explicit server control for Linux.
Omarchy Server is a server-oriented Omarchy fork for serious homelabs and small on-premises clusters. It explores one administrative model for workload identity, resource access, isolation, auditing, virtualization and desired state.
01 / Core vision
One model above existing Linux mechanisms.
Linux already provides strong primitives for process isolation, mandatory access control, resource limits and virtualization. Omarchy Server does not replace those primitives. It defines a smaller administrative model and compiles that model into existing enforcement mechanisms.
P-02
Policy is expressed once.
Administrators define intended access and resource relationships. Backend-specific configuration is generated from that declaration.
P-03
Effective access must be explainable.
The system must answer what a workload can access, what denied an operation, and which policy rule produced the result.
P-04
Kernel enforcement remains authoritative.
Userspace policy is not a substitute for enforcement. Linux security and isolation mechanisms remain the actual boundary.
P-05
Single-host operation is complete.
A machine must remain administrable without a cluster controller, cloud service or external identity platform.
P-06
Unmanaged state is explicit.
Changes outside the managed model are visible as unmanaged or drifted state. The system does not claim authority it cannot verify.
Current work: E-02 live authority reconstruction.
R04 found no current requirement for a kernel fork. The immediate gate is an adversarial prototype that launches a managed workload, reconstructs credentials, cgroups, namespaces, capabilities, seccomp, LSM/Landlock/network state and open descriptors, then reports either a proved result or explicit INDETERMINATE.
02 / Architecture
NT-inspired semantics. Linux implementation.
Windows NT centralized resource representation and security around objects, access tokens, security descriptors and access checks.[1][2] Omarchy Server studies those durable abstractions without attempting Windows compatibility or an NT kernel reimplementation.
Administrative model
The public model is intentionally smaller than the implementation surface.
- principal — stable identity
- workload — managed execution unit
- resource — typed object with defined rights
- policy — declared relationship between principals and resources
- audit — normalized record of security-relevant decisions
- host — independently functional policy and execution boundary
Omarchy policy + object modelidentity · resources · rights · audit
Workload managersystemd · service lifecycle · cgroups
Isolation adaptersnamespaces · seccomp · Landlock
Security adaptersLSM · BPF LSM · ACLs · capabilities
Network + device adaptersnftables · cgroup/BPF · device policy
Virtualization adaptersKVM · libvirt / OCI runtime
Linux kernelscheduler · VM · drivers · filesystems · networking
03 / Object model
Small vocabulary. Typed rights.
The initial model keeps only concepts that improve server administration. NT's Object Manager is useful as prior art because it centralizes creation, naming, lifetime and access tracking for system objects.[3] Omarchy Server applies that idea selectively at the management layer.
principalStable identity
Persistent project identity independent of transient UID/GID assignment. Human-readable names remain aliases.
workloadExecution context
Service, container, VM or agent with identity, runtime policy, limits and lifecycle.
resourceTyped target
Filesystem tree, service, socket, secret, device, GPU, VM, volume or other managed target.
descriptorAccess + audit policy
Declared rights and audit rules attached to a resource, inspired by NT security descriptors.[4]
roleReusable policy set
Named rights that can be assigned to principals without encoding backend-specific groups or labels.
hostLocal authority
Independent machine that resolves and enforces its own effective configuration.
policy bundleDesired state
Versioned configuration that can be validated, signed and optionally distributed to multiple hosts.
eventNormalized audit record
Principal, workload, resource, operation, decision, rule, host and backend evidence in one schema.
04 / Required interface
Access must be queryable before it is automated.
The first architecture test is not whether a policy can be enforced. It is whether the system can accurately explain effective authority across all enabled backends.
shellproposed interface
$ omarchy access workload:subject-a PRINCIPAL principal:subject-a HOST host:local RESOURCE filesystem:data-a filesystem.read-data ALLOW filesystem.write-data ALLOW RESOURCE network:endpoint-a network.connect ALLOW $ omarchy why workload:subject-a filesystem.write-data filesystem:data-a --live DECISION ALLOW COMPLETENESS COMPLETE GRANT descriptor:data-a / filesystem.write-data GATES descriptor, namespace, DAC, LSM, live-authority scan $ omarchy why workload:subject-a filesystem.read-data filesystem:data-b --live DECISION DENY COMPLETENESS COMPLETE DECISIVE GATE no matching managed grant # Names are schematic. The interface describes authority, not an application profile.
05 / Threat model
Managed workloads are untrusted. Host root is trusted.
The first security boundary is deliberately narrow: protect managed resources and workloads from compromised workloads while making drift, unknown gates and incomplete evidence explicit. A malicious host administrator, kernel compromise or firmware compromise is outside the v0 claim.
T-01
Default deny in managed territory.
A managed resource grants no workload authority merely because it exists or is reachable. Access is declared through typed resource policy.
T-02
Unknown state is not silently trusted.
Unknown seccomp, LSM, BPF, namespace or other relevant state can make an access answer INDETERMINATE. The system does not convert missing knowledge into allow or deny.
T-03
Desired policy is not live authority.
Compiled artifacts, observed backend state and already-acquired FDs, sockets, devices and credentials are separate evidence layers.
T-04
Prefer narrow operations over ambient privilege.
Infrastructure workloads should invoke typed brokered operations such as snapshot creation rather than receiving unrestricted mount, device or host-administration capabilities.
Threats that must produce a defined result
- compromised workload attempts lateral filesystem, network or device access;
- workload preserves authority across policy change through an open FD, socket or delegated credential;
- backend configuration drifts from compiler output;
- an unknown external security gate exists;
- namespace/mount/path changes alter resource reachability;
- UID/GID or device-path reuse changes the backend object behind a project identity;
- a privileged helper is used as a confused deputy;
- audit evidence is missing or contradictory.
Full first-pass threat model: docs/THREAT-MODEL.md.
06 / Policy grammar
Allow-only grants. Separate monotonic restrictions.
The v0 grammar is a design fixture, not an API promise. It tests whether real workloads can be described without exposing systemd, seccomp, nftables, LSM or cgroup syntax. Managed resource access is default-deny; general ordered explicit-deny ACL semantics are deferred.
policy.yamlv0alpha1 design fixture
apiVersion: omarchyserver/v0alpha1
kind: PolicyBundle
metadata:
name: host-r940-01
revision: 42
principals:
- id: principal:subject-a
type: workload
resources:
- id: filesystem:data-a
type: filesystem
locator: { path: /srv/example/data-a }
descriptor:
allow:
- subject: principal:subject-a
rights: [filesystem.read-data, filesystem.write-data]
audit:
denied: always
workloads:
- id: workload:subject-a
principal: principal:subject-a
runtime:
kind: service
exec: { path: /usr/bin/example-service }
restrictions:
filesystem:
visible: [filesystem:data-a]
privilegeEscalation: false
limits:
memory: { max: 1GiB }
pids: { max: 64 }
V0 semantic rules
- Stable IDs: project principal/resource IDs are security identities; display names and UID/GID mappings are aliases/backend state.
- Typed rights: use filesystem.read-data, network.connect, gpu.compute, volume.snapshot, etc.; avoid universal rwx or admin.
- Separate restrictions: namespace visibility, seccomp, Landlock/LSM and network restriction may deny an operation that a descriptor grants.
- Explicit composition: roles compose named grants; v0 has no implicit role or ACL inheritance.
- Fail closed: unsupported required semantics fail validation/launch instead of weakening policy.
- Compiler provenance: bundle revision, host capability fingerprint, selected adapters and generated artifact digests remain inspectable.
Full grammar and compiler contract: docs/POLICY-GRAMMAR.md.
07 / Audit + explanation
Every authority claim carries evidence and completeness.
The normalized event model connects declared policy, compiler provenance, observed runtime state and backend evidence. omarchy why is a projection of that trace, not a separate reasoning system. Missing material evidence produces INDETERMINATE rather than a guessed allow result.
eventNormalized observation
Host, principal, workload, resource, operation, timestamp and source identity. Backend-native evidence remains attributable to its actual source.
gateIndependent decision point
Descriptor, namespace, DAC, Landlock/LSM, seccomp, network, device, broker or external state evaluates independently as allow, deny, not-applicable or unknown.
evidenceObserved state
Live cgroup, namespace, process, ruleset, LSM or descriptor observations are distinct from desired policy and compiled artifacts.
completenessClaim boundary
COMPLETE, PARTIAL or UNKNOWN states whether every material gate needed for the answer was actually resolved.
shellschematic decision trace
$ omarchy why workload:subject-a network.connect network:endpoint-a --live REQUEST operation network.connect resource network:endpoint-a target tcp 203.0.113.10:443 RESULT decision ALLOW completeness COMPLETE POLICY bundle host-r940-01@42 grant grant:subject-a-endpoint-a restriction restriction:subject-a-network GATES resource descriptor ALLOW managed · compiled + observed network namespace ALLOW managed · observed network policy ALLOW managed · compiled + observed seccomp ALLOW managed · provenance + observed LSM / Landlock N/A no relevant gate external gates CLEAR no material unknown gate detected EVIDENCE policy bundle sha256:... compiler manifest sha256:... cgroup + namespace observed live nft ruleset observed live proc status observed live CONCLUSION New connection authority is proved for the declared resource.
Audit/explanation invariants
- Intent is not proof: desired policy, compiled artifacts and observed live state remain separate evidence layers.
- Several gates, one trace: Linux mechanisms stay independent; the explanation normalizes their results without pretending they are one ACL.
- Acquisition differs from possession: new access may be denied while an already-open FD, socket, device handle or credential still carries authority.
- Allow requires completeness: a material unknown gate prevents a normal ALLOW claim.
- Append-only observations: drift, broker actions, evidence gaps and explanation queries create records rather than rewriting history.
- No secret capture requirement: explanation metadata must not require logging raw secret values or arbitrary file contents.
Full event envelope, gate schema, live-authority edge case and worked traces: docs/AUDIT-EXPLANATION.md.
08 / Design archaeology
Keep durable abstractions. Remove platform history.
The project starts from original NT design material, checks which concepts remain central in current Windows, then maps only the surviving useful semantics onto Linux. Modern Windows Server configuration is treated as operational evidence, not as a feature checklist.
Phase 0 gating questions
- Can effective authority be computed across every enabled backend, with an explicit completeness result?
- Can the declared security and resource semantics be enforced using upstream Linux mechanisms without a kernel fork?
- Can out-of-band changes that invalidate policy be detected and reported as drift or unmanaged state?
- Can an administrator understand a workload policy without reading generated systemd, LSM, nftables, cgroup or namespace configuration?
- Can every allow or deny answer identify the policy rule and backend evidence that produced it?
R01 · Original NT design
FIRST PASSExtracted the original Object Manager/security invariants and separated them from NT-specific machinery.
- common resource envelope + typed rights
- caller context separate from resource policy
- granted handle authority is live state
- Job Objects moved to R02 as later prior art
R02 · Modern Windows continuity
FIRST PASSThe original token/descriptor/typed-rights core survived, but modern authorization composes several independent gates around it.
- restricted tokens + mandatory integrity
- Job Objects separate grouping from security
- AppContainer adds named capabilities
- full ACL inheritance deferred
R03 · Windows Server operations
ACTIVETreat current Server behavior as operational evidence, not a feature checklist.
- OSConfig desired state and drift control
- role-aware baselines
- audit policy and event selection
- configuration authority and verification
R04 · Linux substrate
FIRST PASSUpstream Linux appears sufficient for the first architecture; the hard problem is reconstructing combined live authority without overstating certainty.
- systemd + cgroup v2 for workload/runtime control
- compiler provenance required for seccomp/LSM/BPF
- Landlock fits monotonic restriction profiles
- open FDs + unknown gates drive completeness
R05 · Comparative prior art
OPENUse narrow comparisons where another system can challenge or simplify the model.
- NixOS desired-state and rollback
- FreeBSD Capsicum descriptor rights
- OpenBSD pledge/unveil self-restriction
- avoid broad OS feature comparison
R06 · Formal model
FIRST PASSA provisional v0alpha1 grammar now tests the model against concrete workloads without committing to a final serialization/API.
- default-deny + allow-only resource grants
- typed rights + explicit role composition
- separate monotonic restriction gates
- compiler provenance + fail-closed semantics
R07 · Threat model
FIRST PASSManaged workloads are untrusted; host root/kernel/compiler remain inside the initial trust boundary.
- drift/unknown gates drive completeness
- live authority survives desired-policy changes
- narrow brokers preferred to ambient privilege
- malicious root/kernel compromise out of v0 scope
R08 · Falsification prototypes
OPENPrototype the parts most likely to disprove the architecture before expanding scope.
- systemd-only managed workload
- live effective-access reconstruction
- Landlock and BPF LSM experiments
- drift injection and three-runtime test
R11 · Audit + explanation
FIRST PASSA normalized evidence model now defines how policy, compiler provenance, live backend state and acquired authority become an explainable access result.
- append-only event envelope + explicit evidence source
- independent gate records + completeness state
- new acquisition separated from existing authority
- schematic ALLOW / DENY / INDETERMINATE traces
Detailed work program: docs/RESEARCH.md. R01: original NT model. R02: modern Windows continuity. R04: Linux substrate. R06: policy grammar. R07: threat model. R11: audit + explanation. Statements are labeled KNOWN, HYPOTHESIS, OPEN, DECISION or DEFER.
R01 provisional result
- Common resource envelope: managed resources share identity, type, policy, backend locator and provenance metadata.
- Typed rights: common rights exist only where they are semantically valid; resource types define their own precise operations.
- Separate inputs: caller/workload context and resource policy remain distinct inputs to access resolution.
- One access semantic: every query resolves to ALLOW, DENY or INDETERMINATE.
- Granted authority is state: open descriptors and other already-acquired capabilities must be considered when reporting effective access.
| Concept | Original NT purpose | Omarchy Server decision | Status |
|---|---|---|---|
| Object / common header | Give different resources a common management envelope for naming, protection, tracking and generic operations.[1] | Common management-level resource record plus a type-specific body. No kernel-object emulation. | KEEP |
| Object type | Define type-specific data/operations while preserving generic object services. | Each managed resource type defines its rights vocabulary and adapter behavior. | KEEP |
| Object namespace | Name selected objects so they can be discovered and shared through a common hierarchy. | Stable resource IDs + aliases. No global NT-style object namespace unless a concrete requirement appears. | ADAPT |
| Handle | Opaque per-process reference carrying granted rights; also participates in lifetime/accounting.[17] | No universal project handle API. Treat already-acquired Linux FDs/capabilities as live authority that effective-access analysis must consider. | ADAPT |
| Security Reference Monitor | Centralize object access enforcement and auditing instead of scattering authorization semantics.[18] | One semantic resolver/compiler; actual enforcement remains in Linux kernel backends. | KEEP / ADAPT |
| Access token | Represent execution security context: identity, groups, privileges and defaults.[5] | Computed, inspectable workload security context. No NT-token binary/API clone. | ADAPT |
| Security descriptor / ACL | Attach resource protection policy and auditing intent to securable objects.[4] | One project descriptor for access + audit intent; defer Windows ACE ordering/inheritance semantics. | KEEP / ADAPT |
| Standard + type-specific rights | Combine operations common to many objects with rights meaningful only to a particular object type.[19] | Small common rights set plus typed rights. Do not force every resource into rwx. | KEEP |
| Privilege | Exceptional authority outside ordinary resource ACL grants; some operations require a privilege. | Small explicit privilege vocabulary mapped to Linux mechanisms; never expose raw CAP_SYS_ADMIN as the conceptual model. | KEEP / ADAPT |
| Process / thread | Process owns address space/resources; threads execute within it. Original NT did not use a general parent/child process hierarchy.[20] | Runtime implementation facts. The administrative unit is a workload backed by cgroup/systemd; R02 uses modern Job Objects as process-grouping/resource-control prior art. | ADAPT |
| Retention + object quotas | Track lifetime and charge processes for object-backed resource use. | Leave to Linux/runtime primitives; surface only when required for truthful authority or resource reporting. | DROP / MOVE DOWN |
R02 first-pass result
- The core survived: modern Windows still separates caller security context (token) from resource policy (security descriptor) and evaluates typed access rights.[2]
- One explanation can contain multiple gates: Mandatory Integrity Control is evaluated in addition to the DACL, and restricted tokens can impose another restricting check.[23][22]
- Grouping is not identity: Job Objects group processes for limits, accounting and lifecycle; modern Windows requires process security limits to be applied separately.[24]
- Sandboxing can extend the core: AppContainer adds application identity and named capability SIDs while continuing to use tokens and DACLs.[25]
- Inheritance is optional complexity: Windows ACL propagation is powerful but has enough flags, precedence and protection rules that Omarchy Server will start with explicit policy + reusable templates instead.[26]
| Modern addition / continuity | What Windows demonstrates | Omarchy Server extraction | Status |
|---|---|---|---|
| Token + descriptor core | Still the basic split between caller context and securable-object policy. | Keep workload-context distinct from a resource descriptor. | KEEP |
| Restricted tokens | Privileges and identity contributions can be removed or constrained; restriction can only reduce the usable authority of the base context.[22] | Study monotonic restriction profiles for agents and sandboxes. | ADAPT |
| Mandatory Integrity Control | A mandatory gate can deny an operation before discretionary ACL evaluation.[23] | One normalized access result may compose multiple independent enforcement gates. Do not copy the Windows integrity lattice. | LESSON |
| Job Objects | Process grouping, limits, accounting and group lifecycle are useful independently of access-token security.[24] | workload maps to systemd/cgroup grouping; security context remains separate. | KEEP / ADAPT |
| AppContainer capabilities | Stable application identity + named capabilities can reuse an existing security model to create a default-deny sandbox.[25] | Study server-oriented named capabilities; drop package/MSIX/UI semantics. | ADAPT |
| ACL inheritance | Automatic hierarchical policy propagation solves real problems but introduces explicit/inherited precedence, flags and protected ACL state.[26] | Explicit descriptors and reusable templates first. No Windows inheritance clone in v0. | DEFER |
| SACL + host audit policy | Resource audit intent and system-wide collection policy are separate layers.[27] | Descriptor expresses what matters; host policy controls collection, retention and forwarding. | KEEP / ADAPT |
| Dynamic Access Control | Claims, resource attributes and central policy address enterprise authorization scenarios but add directory and expression complexity.[28] | Defer general ABAC/claims until explicit roles and typed resources prove insufficient. | DEFER |
| Declarative sandbox spec | Microsoft now documents an experimental launch specification that composes identity, AppContainer, filesystem, network, integrity and Job restrictions behind one interface.[29] | Useful prior art for a compiler over heterogeneous enforcement mechanisms; not a schema or dependency. | REFERENCE |
R04 first-pass result
- No kernel-fork gate found: systemd/cgroup v2, credentials/capabilities, namespaces, seccomp, LSMs, Landlock and network policy cover the first architecture's enforcement needs. The remaining gate is proving effective runtime authority.
- Enforcement is not enough: seccomp exposes filter mode/count through /proc, but full filter semantics are not ordinarily reconstructed from passive runtime state. Managed policy provenance is therefore part of the security model.[31][33]
- Grouping remains separate from identity: cgroup v2 provides hierarchical membership, accounting, limits and delegation; it is the workload resource substrate, not the principal model.[30]
- Namespaces are access gates: namespace membership is inspectable through /proc/<pid>/ns, but filesystem, capability and network conclusions can be namespace-relative.[32]
- Monotonic restriction is viable: current Landlock stacks restrictions and now exposes denial audit/trace evidence, but coverage and ABI version must be negotiated per host.[34][35]
- Live authority includes acquired objects: open descriptors remain part of the workload's authority even after desired policy changes. fdinfo becomes an input to live access reconstruction.[39]
| Linux mechanism | Enforcement | Runtime introspection | Omarchy Server use |
|---|---|---|---|
| systemd + cgroup v2 | Lifecycle, grouping, CPU/memory/IO/PID limits, device attachment points. | Strong: unit/cgroup membership and controller values are readable. | Default Phase-1 workload adapter; generated state is verified, not blindly trusted.[30] |
| UID/GID + ACL + capabilities | Filesystem DAC and exceptional process privilege. | Strong for credentials/capability masks; filesystem result also depends on namespace, ACL and other gates. | Backends behind stable project principals and semantic privileges.[31][38] |
| Namespaces | Visibility and scope isolation. | Membership is strong; the effective resource view sometimes requires namespace-relative inspection. | Report as reachability/scope gates, not descriptor permissions.[32] |
| seccomp | Strong syscall restriction; filters can layer and persist across exec. | Partial from ordinary runtime state; filter mode/count are visible, complete filter meaning needs retained policy or privileged inspection. | Compiler-owned policy + digest/provenance. Unknown filters can force INDETERMINATE.[33] |
| LSM / Landlock / BPF LSM | Kernel MAC and stackable workload restrictions. | Varies by backend. Landlock denial provenance is now strong; BPF LSM can be designed to emit project evidence. | Detect active LSMs; prefer Landlock where covered; defer BPF LSM to later gaps/provenance needs.[34][35][36] |
| nftables / cgroup network policy | Strong packet/socket policy. | Rulesets are readable; tracing can identify packet rule traversal. | Bind policy to workload/cgroup identity where practical. Hostname/DNS authorization remains an explicit open problem.[37] |
| Open FDs / fdinfo | Already-acquired authority rather than a policy backend. | Partial-to-strong depending on object type. | Mandatory input to omarchy access --live; unmodeled descriptor types are surfaced, not ignored.[39] |
09 / Roadmap
Architecture first. Enforcement second.
Each phase has an explicit exit condition. Later phases should not proceed if the earlier abstraction cannot produce an accurate effective-access model.
Phase 0
Model
Model
Literature review and formal vocabulary
Define resource types, principal semantics, rights, descriptors, inheritance, audit semantics and managed/unmanaged boundaries.
- NT 3.1 design extraction
- modern Windows survival check
- Linux mechanism capability matrix
- threat model and non-goals
Exit: a backend-independent policy can represent several real server workloads without referring to systemd, SELinux, nftables or other implementation-specific syntax.
Phase 1
Local
Local
Managed workload runtime
Create and run managed services with declarative identity, lifecycle, resources and isolation using existing Linux components.
- systemd service generation
- cgroup v2 limits and accounting
- dynamic/local identities
- mount/user/network namespaces where required
- capability and seccomp policy
- nftables and journald adapters
Exit: omarchy workload create/start/stop/inspect can manage a production-like service without manual backend configuration.
Phase 2
Access
Access
Stable principals and effective-access resolver
Add persistent principal IDs, typed resources, descriptors, policy compilation and normalized audit records.
- omarchy access
- omarchy why
- omarchy audit
- configuration validation and drift detection
Exit: the system can explain the effective authority of every managed workload and identify unmanaged state that makes an answer incomplete.
Phase 3
Kernel
Kernel
Stronger policy enforcement
Evaluate LSM, BPF LSM and Landlock as enforcement/audit backends. BPF LSM can attach programs to LSM hooks for MAC and audit policy; Landlock can add stackable restrictions to processes.[7][8]
- backend coverage tests
- denial provenance
- signed/validated policy artifacts
- fail-closed behavior for declared managed workloads
Exit: policy decisions and audit evidence remain consistent across supported kernel backends and survive adversarial bypass tests.
Phase 4
VM/OCI
VM/OCI
Virtual machines and containers as workloads
Apply the same principal/resource/policy model to KVM guests and OCI-style containers without making either runtime the top-level administrative abstraction.
- VM disks, NICs and devices as resources
- GPU/device assignment policy
- container identity and network policy
- backup/snapshot hooks
Exit: a service, container and VM can be queried through the same access and audit interface.
Phase 5
Cluster
Cluster
Optional multi-host control
Add inventory, signed policy distribution, host status and drift reporting while preserving complete standalone operation.
- host enrollment and trust
- signed policy bundles
- resource inventory
- remote execution with explicit authorization
- cluster-wide access graph
Exit: disconnecting the controller does not prevent local administration or enforcement on any enrolled host.
10 / Non-goals
Scope is intentionally narrow.
The project is not an attempt to reproduce the Windows ecosystem or replace mature Linux subsystems.
No Linux kernel fork
Kernel changes are not part of the initial architecture. Existing upstream interfaces are preferred.
No Windows compatibility layer
The project borrows selected administrative and security concepts, not Windows APIs or application compatibility.
No Active Directory clone
Enterprise directory services are outside the first target. External identity can be integrated later.
No Kubernetes replacement
The primary unit is the host and its managed workloads. Cluster orchestration is optional and limited in scope.
No hidden Linux
Generated system configuration and backend state must remain inspectable with normal Linux tools.
No false single source of truth
Root-level unmanaged changes can invalidate the model. Drift and unmanaged state must be reported rather than ignored.
11 / Builder handoff
The site is also the implementation specification.
This section defines what a site-building agent may change, what it must preserve, and the acceptance criteria for a production implementation. The research documents are authoritative for technical claims; this page is the canonical product and presentation brief.
B-00 / Builder contract
Preserve meaning. Improve implementation.
The builder may replace the current HTML/CSS structure, componentize the site, introduce a static-site framework, and redesign individual cards or responsive behavior. It must preserve the project's factual status, technical distinctions, citations, uncertainty markers, non-goals, and research decisions.
- Do not claim an Omarchy Server release, repository, package, benchmark, security guarantee, partnership, endorsement, or completed implementation unless the source content is updated to establish it.
- Do not describe this as an official Omarchy or Omacom project. The pink unofficial-fork banner remains prominent on every page/view.
- Do not convert KNOWN / HYPOTHESIS / OPEN / DECISION / DEFER into undifferentiated prose.
- Do not reduce access reasoning to a binary answer when the model requires INDETERMINATE.
- Do not make backend mechanisms such as systemd, Landlock, seccomp, LSM/BPF or nftables look like the public product model.
B-01 / Audience
Technical operators and contributors.
- Serious homelab operators.
- Small and medium on-premises infrastructure teams.
- Linux and Windows systems engineers evaluating the architecture.
- Open-source contributors looking for concrete research or implementation work.
Assume technical literacy. Define project-specific terms; do not explain basic Linux, virtualization, or operating-system concepts unless necessary to distinguish semantics.
B-02 / Message hierarchy
What a reader should learn in order.
- This is an independent experimental Omarchy fork.
- The target is explicit server control for one host first, then small clusters.
- The thesis is a smaller administrative model above existing Linux primitives.
- NT is research input, not an API-compatibility target.
- The research is incomplete and has explicit falsification gates.
- The project currently has no release.
B-03 / Information architecture
Top-level views are stable.
- Overview — thesis, target, principles, project status.
- Architecture — object model, access/explanation interface, threat model and policy grammar.
- Research — workstreams, gating questions, matrices, documents.
- Roadmap — phased implementation with exit criteria and non-goals.
- Build Spec — this implementation handoff.
- References — primary/authoritative sources behind claims.
Deep links must continue to open the correct view and target. Browser back/forward behavior must work.
B-04 / Visual system
Technical, dark, restrained.
- Black/near-black base, low-contrast grid or technical texture permitted.
- Acid/lime green is the primary project accent.
- Pink is reserved for the unofficial-fork notice and warnings of that class.
- Monospace type is used for labels, commands, state and metadata; readable sans-serif for prose.
- Square or lightly squared geometry; avoid glossy SaaS gradients, oversized illustrations, mascots, stock art, or generic AI imagery.
- Dense information is acceptable, but visual hierarchy must remain obvious.
B-05 / Interaction
Fast and deterministic.
- Tabbed navigation is the primary desktop and mobile information architecture.
- Tabs are keyboard navigable and expose correct ARIA relationships.
- Hash/deep-link navigation must reveal hidden tab content automatically.
- Reference links from any tab must open the References tab at the cited item.
- Mobile tab navigation may horizontally scroll; do not hide core sections in a hamburger-only menu.
- Respect reduced-motion preferences. No animation is required for comprehension.
B-06 / Content rules
Claims must remain auditable.
- Architectural claims depending on external behavior should cite primary or authoritative documentation.
- Historical NT claims should distinguish original NT 3.1 design from later Windows additions.
- Modern Windows and Windows Server features are evidence streams, not automatically project requirements.
- Linux mechanisms are implementation candidates; document enforcement, introspection and explanation separately.
- When research changes a decision, update the public matrix, the research document and the decision log together.
B-07 / Technical constraints
Static-first deployment.
- The deployed site must work on ordinary static hosting and the omarchyserver.com custom domain.
- No server-side runtime is required for core reading/navigation.
- Progressive enhancement is preferred; critical content must remain renderable without a heavy client application.
- External analytics, trackers, fonts or JavaScript dependencies are not required.
- Keep metadata, canonical URL, sitemap, robots policy, favicon and social metadata valid.
- Source should remain straightforward for contributors to edit without a proprietary build service.
B-08 / Source of truth
Research and site content have different roles.
- docs/RESEARCH.md is the research index, status vocabulary, gating program and decision-log entry point.
- R01, R02, R04 and later reports are the detailed evidence record.
- docs/THREAT-MODEL.md and docs/POLICY-GRAMMAR.md are Phase-0 design documents.
- Application-specific workload scenarios are not part of the product or website specification. Synthetic conformance/unit tests may exist in implementation code, but the site must not present named workloads as required fixtures.
- The website summarizes those documents for readers and contributors.
- docs/BUILD-SPEC.md is the expanded handoff for the site implementation agent.
Where the website and a research document disagree on a technical finding, the research document wins until both are reconciled.
B-09 / Terminology
Use terms consistently.
- principal — stable identity used in authorization.
- workload — managed execution unit; may contain one or more processes.
- resource — typed managed object against which operations are expressed.
- descriptor — project-level access and audit intent for a resource.
- restriction — workload-side monotonic gate that can reduce usable authority independently of a resource grant.
- broker — trusted narrow host service exposing a typed privileged operation without granting ambient host privilege to the caller.
- gate — one enforcement/restriction mechanism contributing to effective authority.
- effective authority — what the workload can actually do now, including acquired authority and active restrictions.
- drift — runtime/backend state inconsistent with declared managed state.
- unmanaged — state outside the project's declared control or visibility.
B-10 / Acceptance criteria
A production site implementation is complete when:
- All six top-level views are reachable by mouse, keyboard and direct URL hash.
- Deep citation links reveal hidden reference content correctly.
- The unofficial-fork notice is visible before the main navigation.
- Desktop, tablet and phone layouts preserve all technical content without horizontal page overflow.
- Wide research tables remain usable through contained horizontal scrolling or an equivalent responsive representation.
- Heading order, landmarks, tab semantics, focus states and contrast are accessible.
- The site works with reduced motion and remains readable with JavaScript unavailable; tab fallback may show all sections.
- No unsupported project-status claims have been added.
- Every citation target and local research-document link resolves.
- No duplicate HTML IDs or broken internal anchors remain.
- Canonical metadata points to https://omarchyserver.com/.
- The build/deploy path is documented and reproducible on an ordinary local machine.
Expanded implementation handoff: docs/BUILD-SPEC.md
About
About OmarchyServer.com
Project identity and relationship to upstream Omarchy.
First things first, this site is not an official Omarchy site! Omarchy also has an “Omarchy Server” listed as “Coming Soon”, so please be certain to note that our project here is just a research project.
Our goal is to bring a Windows NT/Server architecture into Omarchy as a unifying layer atop the Linux kernel.
Finally, if you represent Omarchy and you would prefer to have this domain name, we'll gladly donate it.
12 / Literature
Primary references.
These sources define the current research baseline. The project should add references when an architectural decision depends on them.
[1]
Helen Custer — Inside Windows NT (1993), Chapter 3
Original NT description of the Object Manager and object security. Useful for recovering design goals before later Windows compatibility layers accumulated.
[2]
Microsoft — Parts of the Access Control Model
Current description of access tokens and security descriptors as the two basic parts of the Windows access-control model.
[3]
Microsoft — Windows Kernel-Mode Object Manager
Current Object Manager responsibilities: object lifecycle, namespace, resource tracking and access rights.
[4]
Microsoft — Security Descriptors
Owner, DACL, SACL and control information associated with a securable object.
[5]
Microsoft — Access Tokens
Current definition of process/thread security context, including account and group SIDs and privileges.
[6]
Microsoft — OSConfig for Windows Server
Modern Windows Server desired-state configuration, scenario-based baselines and drift control.
[7]
Linux kernel documentation — BPF LSM Programs
Runtime attachment of privileged eBPF programs to LSM hooks for mandatory access-control and audit policies.
[8]
Linux kernel documentation — Landlock
Stackable, process-scoped restrictions intended to reduce ambient rights and constrain untrusted user-space programs.
[9]
Linux kernel documentation — Linux Security Modules
Framework for additional access controls and security contexts in the Linux kernel.
[10]
systemd — systemd.exec / systemd.resource-control
Candidate workload backend for process supervision, sandboxing, identities, capabilities and cgroup-based resource control.
[11]
Microsoft Sysinternals — Windows Internals
Modern continuity check. Microsoft identifies the current series as the continuation of Custer's original Inside Windows NT; the 7th edition still treats architecture, processes/jobs and security as major system topics.
[12]
NixOS Manual — Declarative system configuration
Prior art for desired-state configuration, reproducibility and rollback. Relevant to policy application and host state, not to the security object model itself.
[13]
FreeBSD — Capsicum capability rights
Prior art for rights attached to file descriptors and monotonic reduction of authority after a descriptor has been obtained.
[14]
OpenBSD — pledge(2)
Prior art for a deliberately small, application-facing self-restriction vocabulary. Useful as a counterexample to exposing low-level kernel policy directly.
[15]
Linux man-pages — seccomp(2) and capabilities(7)
Authoritative interfaces for syscall filtering and split process privileges; both are candidate implementation mechanisms rather than public policy concepts.
[17]
Microsoft — Requesting Access Rights to an Object
Current confirmation that a handle is opened with a granted set of rights and should request only the authority required.
[18]
Microsoft — Windows Kernel-Mode Security Reference Monitor
Current description of the SRM as a core kernel component for access control, privilege checks and security auditing.
[19]
Microsoft — Access Rights and Access Masks
Current standard/generic/type-specific rights model used when requesting and granting access to securable objects.
[20]
Microsoft — Processes and Threads / Job Objects
Modern continuity source. Job Objects manage groups of processes as a unit; this is later prior art and is not attributed to the original NT 3.1 process model.
[22]
Microsoft — Restricted Tokens
Modern token restriction can remove privileges, make SIDs deny-only, and impose a second restricting-SID access check.
[23]
Microsoft — Mandatory Integrity Control
Mandatory integrity policy is evaluated in addition to discretionary access control and can deny access even when a DACL permits it.
[24]
Microsoft — Job Objects / Job Object Security
Modern process-grouping, accounting, limits and nesting; current Windows applies security limitations to processes rather than using job-wide security limits.
[25]
Microsoft — AppContainer
Application sandboxing built from package identity, capability SIDs, tokens, DACLs and additional isolation mechanisms.
[26]
Microsoft — ACE Inheritance
Modern ACL propagation rules include inheritance flags, explicit/inherited precedence, object-specific inheritance and protected ACLs.
[27]
Microsoft — Audit Generation / Server Audit Policy
Object SACLs describe auditable access while host audit policy controls broader event collection and operational recommendations.
[28]
Microsoft — Centralized Authorization Policy
Windows Dynamic Access Control adds claims, resource attributes and centrally managed conditional authorization for enterprise scenarios.
[29]
Microsoft — Create Process in Sandbox (experimental)
Current experimental API composes identity, AppContainer, integrity, filesystem, network, capability and Job restrictions in one launch specification.
[30]
Linux kernel — Control Group v2
Hierarchical process grouping, resource controllers, delegation and cgroup-BPF device policy. Primary substrate for workload membership and resource control.
[31]
Linux man-pages — proc_pid_status(5)
Readable live process state including UID/GID, capability sets, NoNewPrivs, seccomp mode and attached-filter count.
[32]
Linux man-pages — namespaces(7) / user_namespaces(7)
Namespace isolation, /proc namespace identities and the namespace-relative scope of credentials and capabilities.
[33]
Linux man-pages — seccomp(2)
Syscall filtering, filter stacking/inheritance and privileged filter inspection. Ordinary /proc state does not itself describe the complete filter program.
[34]
Linux kernel — Landlock: unprivileged access control
Stackable monotonic restriction domains, versioned access-right coverage and current filesystem/network/IPC-scoping semantics.
[35]
Linux kernel — Landlock system-wide management
Denial audit records and tracepoints carrying blocker/domain/object evidence plus deeper policy-debugging observability.
[36]
Linux kernel — LSM BPF Programs
Runtime eBPF attachment to LSM hooks for system-wide MAC and audit policy. Candidate advanced project-specific backend.
[37]
nftables — nft manual
Current ruleset language includes cgroup-v2 socket matching and monitor/trace facilities for rule and packet traversal evidence.
[38]
Linux man-pages — acl(5)
POSIX ACL access-check algorithm, masks and default-ACL inheritance used by the filesystem discretionary-access backend.
[39]
Linux man-pages — proc_pid_fdinfo(5)
Live descriptor metadata, including access flags and object-specific fields, used when reconstructing already-acquired authority.
[21]
Omarchy upstream
Upstream Linux project and technical lineage. Omarchy is MIT licensed; this project is independent.