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.
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 minecraft.prod PRINCIPAL workload:minecraft.prod HOST r940-01 FILESYSTEM /srv/minecraft/prod READ WRITE EXECUTE /srv/minecraft/backups READ everything else DENY NETWORK listen tcp:25565 ALLOW connect dns ALLOW connect db.internal:5432 ALLOW everything else DENY DEVICES gpu:a6000-0 DENY raw block devices DENY $ omarchy why minecraft.prod can-write filesystem:minecraft-world DECISION ALLOW RULE role:game-server / filesystem.write RESOURCE filesystem:minecraft-world BACKENDS mount namespace, LSM policy $ omarchy why minecraft.prod read filesystem:user-ssh DECISION DENY RULE no matching allow rule BACKENDS mount namespace, LSM policy # The report is only valid if every active enforcement layer is represented.
05 / 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 representative workloads 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
ACTIVERecover the original invariants before later Windows product layers accumulated.
- objects, types, names and handles
- Security Reference Monitor and access checks
- tokens, descriptors, ACLs and privileges
- process/thread authority boundaries
R02 · Modern Windows continuity
ACTIVECheck which early NT concepts remain structural in current Windows.
- Object Manager responsibilities
- access token + security descriptor model
- jobs, restricted tokens and inheritance
- audit and handle semantics
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
ACTIVEMap desired semantics to enforceable, inspectable Linux mechanisms.
- systemd + cgroup v2
- capabilities, namespaces and seccomp
- LSM, BPF LSM and Landlock
- network, audit, VM and OCI adapters
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
OPENDefine the semantics before committing to a policy language or backend compiler.
- principal, workload, resource, descriptor
- rights, roles and inheritance
- allow/deny precedence and privileges
- identity lifecycle and dynamic resources
R07 · Threat model
OPENState what the model protects, what is trusted and what invalidates its claims.
- root and local administration trust
- compiler/backend desynchronization
- open-FD, mount and namespace edge cases
- controller, runtime and audit compromise
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
Detailed work program: docs/RESEARCH.md. The research document labels statements as KNOWN, HYPOTHESIS, OPEN, DECISION or DEFER.
| Concept | NT / Windows role | Linux situation | Omarchy Server decision | Status |
|---|---|---|---|---|
| Object / resource type | Uniform representation of securable and kernel-managed resources.[1] | Strong kernel objects, but no single administrative resource vocabulary. | Typed management resources with backend adapters. | KEEP |
| SID / stable principal | Identity separated from display name; tokens carry principal and group SIDs.[5] | UID/GID remains primary Unix identity mechanism. | Stable project identity above UID/GID. | ADAPT |
| Access token | Security context associated with a process or thread.[5] | Credentials, groups, capabilities, namespaces and LSM context are separate mechanisms. | Expose an effective workload security context; do not emulate NT token internals. | ADAPT |
| Security descriptor | Owner, discretionary access policy and audit policy associated with an object.[4] | Equivalent intent is distributed across ACLs and security systems. | Unified access + audit declaration for managed resources. | KEEP |
| Object Manager | Centralized object lifecycle, namespace and access tracking.[3] | No direct administrative equivalent. | Implement only a management-level resource registry and access resolver. | ADAPT |
| Registry | Central Windows configuration database. | Linux configuration is intentionally distributed. | No registry clone. Use versioned declarative project configuration. | DROP |
| Domain / AD integration | Enterprise identity and policy distribution. | Existing LDAP, Kerberos and identity stacks already exist. | Out of initial scope; allow adapters later. | DEFER |
| Desired-state enforcement | Windows Server OSConfig applies scenario-based configuration and drift control.[6] | Many mature tools exist, but no Omarchy-specific policy owner. | Local desired state first; optional signed cluster bundles later. | ADAPT |
06 / 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.
07 / 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.
08 / 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.
[16]
Omarchy upstream
Upstream Linux project and technical lineage. Omarchy is MIT licensed; this project is independent.
Current work: architecture, threat model, policy grammar.
No release exists yet. The next concrete artifact is a formal design matrix covering NT concepts, modern Windows behavior, Linux enforcement options and the project decision for each concept.