Technical Assessment
AM·OS Ghost Net Edition
A privacy and security operating system for self-hosting, on home hardware, in virtual machines, and on servers.
Glossary
-D_FORTIFY_SOURCE, that replaces common string and memory operations with checked variants and aborts on a provable overflow.
.onion address. Reachable only by clients that speak Tor. AM·OS provisions one at node startup.
FROM → RELN → TO, connecting concepts rather than storing raw text. Enforced at the protocol level so every node speaks the same data language.
FROM → RELN → TO, where FROM and TO are neurons and RELN is the relationship between them.
Executive Summary
AM·OS is a privacy and security operating system for individuals who want to run their own web services. Running a public service from home introduces two primary attack vectors. The first is exposure: the moment the machine accepts a connection from the internet, its address is published, its location is discoverable, and the operator's household becomes the target of any attack that follows. The second is intrusion: the same machine is now reachable by remote attackers, and on a home network a successful breach is not contained to the host; every device sharing the connection is behind the same door. AM·OS is built to close both. It removes the exposure of the address while keeping the service reachable from any browser, and it enforces an isolation model in which a compromised application has no path beyond loopback.
This edition of the platform is called Ghost Net Edition. It ships the Tor-native transport, the ADDNS reachability layer, the per-cgroup isolation model, and the full hardening stack described in this document as its default configuration.
Two mechanisms underpin the platform's security posture. Network access is enforced per process through the cgroup hierarchy, so a single machine can host services with fundamentally different network privileges at once. Runtime integrity is enforced by IMA appraisal: every executable and shared library must carry a valid signature before the kernel will run it. The binary hardening of every package is verified by an automated audit rather than asserted.
Against the KSPP kernel recommendations, the platform scores 239 of 260 settings. The remaining 21 are false positives, debug-only options, toolchain requirements, or documented workload exceptions. Against the OpenSSF binary hardening profile, every package in the shipping tree carries the full mitigation set or is covered by a reproducible exception. The integrity model is architecturally equivalent to RHEL 9 and Oracle Linux 9.
The same image runs in a virtual machine, on home hardware, and on a datacenter server. Its primary application is annode, a Java web server that can also serve as a node of the ANNE peer-to-peer network. The P2P integration is optional. AM·OS is a self-hosting web server first, and the ANNE network is available for those who want what it adds on top.
Under the Hood
AM·OS is a custom Linux distribution based on Slackware-current. It supports BIOS and EFI boot, and installs onto ext4, xfs, or btrfs, with optional LUKS2 encryption, dm-integrity, LVM, and secondary data volumes. It runs as a guest under VirtualBox or QEMU, and it installs directly onto physical hardware for home hosting or datacenter deployment. The installer and the hardening posture are identical in every case.
The web service stack comprises MariaDB, MongoDB, Node.js, PHP, a system Tor instance, and annode, a Java application that serves as the platform's web server. Apache and Nginx are not supported. The image also ships a hardened Monero node and a Monero Light Wallet Server. Additional packages are available from the project's own repository, built from source under the same hardening profile as the base image.
The platform follows a curation model similar to Red Hat's: the base image ships a defined, reviewed set, and anything outside that set is built on request. If you need a package that is not currently in the repository, let us know. It will be built from source, hardened to the same standard, signed, and added.
The platform enforces its security policy by default, but nothing is locked away from the operator. IMA appraisal can be disabled, the appraisal policy can be edited, the per-cgroup network rules can be modified, and the kernel hardening profile can be adjusted. Every one of these is a documented, self-contained change. Doing so is at the operator's own risk: the guarantees described in this document assume the shipping configuration. What the platform does provide is transparency. Every setting, every script, and every exception is available in the source tree, and the kernel and binary audits can be rerun at any time to reproduce the exact results reported here.
The remainder of this document describes the security architecture and how it compares to other hardened Linux projects. The sections that follow cover the ADDNS reachability layer, the five layers of the hardening stack, the per-cgroup network isolation model, the kernel and binary audits, and a direct comparison against RHEL, Qubes OS, Whonix, and the other distributions listed at the end.
Hidden Services, ADDNS, and the Clearnet Path
The clearnet path is the platform's central architectural idea, and the mechanism deserves detail.
The hidden-service reachability problem
A Tor onion service is reachable only by clients that speak the Tor protocol. For the majority of internet users, this constraint is disqualifying: a conventional browser cannot resolve a .onion address without additional software, and requiring every visitor to install Tor is not a practical option for a public-facing service. The privacy guarantee the hidden service provides is genuine, but its reachability cost is prohibitive. ADDNS resolves the tension between the two.
Properties of the clearnet path
Every node on the platform provisions its own Tor onion service at startup, with the onion address derived from the node's identifier rather than from its IP address or DNS name; that identifier can be regenerated at will, and an ADDNS mapping can be repointed to a new onion under the same name. ADDNS is a service layer that maps a node's identifier to its onion address and proxies requests between an ordinary browser and the hidden service. The visitor needs no Tor client and no special configuration. The node needs no public IP address and no inbound port. The service is reachable from any browser on the internet, and the machine's location never appears in the protocol.
ADDNS is not a single centralized operator. Any party can run an ADDNS instance: the node operator for their own services, a trusted contact on their behalf, or a public instance offered as a service. ANNE Media operates one such public instance. The mapping from identity to onion address is public and verifiable, so an ADDNS instance cannot silently substitute a different endpoint.
A single ADDNS instance is not a scaling bottleneck, because DNS handles the distribution. The domain's A records point to two or more ADDNS nodes, each with its own priority. Browsers and resolvers distribute requests across them according to those priorities, and if one node becomes unreachable, the resolver falls through to the next. Load balancing happens at the DNS layer, automatically, with no additional infrastructure to configure. Adding capacity means adding an A record. Removing a node means deleting one. The public mapping from identity to onion address is shared and verifiable, so every ADDNS node in the set serves the same authoritative answer, and no coordination between them is required.
| Step | What happens |
|---|---|
| 1. Browser resolves the name | The visitor enters a normal HTTPS URL. DNS resolution reaches the ADDNS layer, which holds the mapping from the node's identity to its onion address. |
| 2. ADDNS routes into Tor | ADDNS opens a Tor circuit to the onion endpoint and forwards the request. It speaks only to the onion address, so it never learns the node's IP address; the node's hidden service receives the request without learning the visitor's IP either, and the visitor's browser never contacts the Tor network directly. |
| 3. The node serves the response | The node processes the request locally, on its own hardware, and returns the response through the same circuit. The node's application never sees the public internet; it sees only the loopback interface and its own Tor daemon. |
| 4. ADDNS returns to the browser | ADDNS decrypts the response and returns it to the browser over ordinary TLS. From the visitor's perspective, the interaction is indistinguishable from any other HTTPS site. |
Guarantees of the clearnet path
Reachability without exposure. The node is reachable from any browser on the internet, and its IP address is never present in any packet that leaves the hidden service. The visitor's browser does not learn the node's location; the node does not learn the visitor's. Neither side needs special software.
No public address, no inbound port. The node does not require a public IP, a static address, a port forward, or a DNS record. A machine behind carrier-grade NAT on a home connection is as reachable as a machine in a rack. This is what makes home hosting a first-class deployment profile rather than a compromise.
Independence from the hosting provider. The node's reachability does not depend on the ISP, the datacenter, or the jurisdiction. If the operator's public IP is blocked or the domain is seized, the hidden service continues to serve. Reachability is a property of the identity, not of the physical location.
Compatibility with ordinary tooling. Because the browser side is an ordinary HTTPS request, the node can serve standard web content: PHP applications, static sites, APIs, and the annode runtime itself. Nothing on the visitor's side needs to know that Tor is involved.
Most systems that use Tor for hosting are reachable only to Tor users. Most systems that are reachable from the clearnet expose the host's IP address. AM·OS provides both properties at once. The ADDNS layer is what makes this possible: a bidirectional proxy that translates between a normal HTTPS request and a Tor circuit without either side needing to know what the other speaks.
Purpose and Target Deployments
The primary workload is a web server, whether that is a conventional PHP site, a Node.js application, or the annode runtime. The ADDNS layer described above is what makes self-hosting practical from any network location, and the hardening layers that follow make it safe to operate. The platform addresses four deployment contexts with one operating system.
| Deployment | Typical constraints | What AM·OS provides |
|---|---|---|
| Virtual machine (VirtualBox, QEMU) | Shared host, no dedicated hardware, needs a portable image that boots cleanly under both BIOS and EFI. Host may be a laptop, a workstation, or a CI environment. | A single image that boots under VirtualBox and QEMU without modification. The same hardening applies inside the guest as on bare metal. Useful for development, testing, and running a node on hardware the operator already owns. |
| Home hosting | No static address, frequently behind carrier-grade NAT, no ability to port forward, ISP may filter or throttle, physical location is the operator's residence. | A reachable service without a public IP or port forward. The ADDNS layer removes the dependence on inbound reachability. The isolation model ensures that a compromise of the node does not expose the home network or leak its location. |
| Server hosting | Public IP by default, subject to IP-based blocking or takedown, operator's location exposed if the service is reachable clearnet, datacenter or jurisdiction may act on complaints. | The same hidden-service transport, so the node does not depend on its public IP for reachability. The public IP can be firewalled off entirely and the node still serves. The operator's location is never disclosed by the protocol. |
| Bare metal, all of the above | Requires BIOS or EFI boot support, and a filesystem layout that works with the operator's hardware. | The same installer that handles VirtualBox and QEMU also handles bare metal on BIOS and EFI, ext4, xfs, and btrfs, with optional LUKS2, dm-integrity, and LVM. |
The operator does not configure a firewall, purchase or renew a certificate, set up port forwarding, or obtain a static IP. The node provisions its own address, its own transport, and its own access controls at startup.
Service configuration
Configuring a web service on AM·OS is substantially simpler than on Apache or Nginx. Those servers require virtual host files, directory directives, module configuration, TLS certificate management, and a running daemon whose defaults must be tightened before the service can safely face the internet. On this platform, none of that applies. A service is defined by pointing a domain to a directory:
# in node.properties
node.DOMAINS = yourdomain.com::/home/you/Apps/yourdomain.comThat single line is the entire service configuration. The directory can live anywhere on the system; there is no fixed web root and no server block to write. The web server is already running, and it reads the mapping directly from the node's configuration.
Exposing that service to the clearnet requires one more entry, on a machine that already holds a public address. Any ADDNS node can serve this role: one the operator runs themselves, one a trusted contact runs, or the public instance operated by ANNE Media. The entry maps the domain to the node's permanent identifier:
# on any public node: yours, a friend's, or ours
node.DDNS = yourdomain.com::1202683298237319346Once that mapping is in place, the service is reachable from any browser on the internet. The ADDNS node resolves the domain, routes the request into the Tor network, and returns the response. Nothing else is required from the operator. There is no firewall rule, no certificate to renew, no reverse proxy, and no load balancer in the path.
What remains for the operator is choosing the hardware, defining what the service does, and deciding who can reach it. Everything else is handled by the platform.
Application development
Development on AM·OS follows the same workflow as development on any other Linux host. An application is deployed by placing its files in the directory assigned to it. PHP, Node.js, and Java all run, and the web server presents a standard HTTP endpoint. Existing tooling is unaffected: Git, IDEs, SSH, database clients, and the local development loop behave as usual. The difference is confined to the network boundary, where requests arrive through Tor and outbound connections leave through Tor. Neither requires code in the application. The infrastructure work that normally accompanies hosting a public service, from hardening the daemon to routing requests from the internet to a running process, is not the developer's concern here.
For developers who want to go further, the annode runtime provides access to the ANNE network. This is not a messaging layer bolted onto a web server. It is a different substrate for applications, and it addresses three problems that conventional web stacks do not solve.
A shared semantic data layer. ANNE stores structured data as triplets of the form FROM → RELN → TO, where each entry connects concepts rather than storing raw text. The format is enforced at the protocol level, so every node speaks the same data language. A record about a person, a place, or an event exists once on the network and is referenced by other nodes rather than duplicated. This is the difference between a shared index and a pile of independent databases. Applications can query the network conceptually, without a third-party API or index in the middle. This schema is called 1SCHEMA, and it is the reason the network can hold a coherent view of its own data instead of a thousand incompatible copies.
Direct node-to-node data distribution. Above the semantic layer sits the Alt Data Network, which propagates state changes, messages, and data operations directly between nodes. It replaces the request-and-response cycle of a client-server backend, the load-balancing tier that sits in front of it, and, in many cases, the DNS layer that resolves names to addresses. Applications can publish and receive typed payloads through this mesh without a central coordinator. The developer does not run a server that others connect to; the network carries the data, and each user's node participates in handling it.
Applications that run locally, on the user's hardware. In the conventional model, the developer hosts the application and the user connects to it. In the ANNE model, the user runs the application on their own node. A marketplace is not a website the user visits; it is an application that runs locally and pulls its data from the network. The developer builds the application once, and it runs on every participating node. This inverts the hosting relationship and removes the developer's need to operate infrastructure at all.
These three capabilities are available alongside the ordinary web-serving stack, not in place of it. A developer can publish a conventional PHP site and an ANNE-integrated application from the same node. The P2P layer is enabled by default; whether an application uses it is entirely the developer's choice. Nothing in the network requires adoption, and nothing about an ordinary application is affected by the network's presence.
For developers interested in what peer-to-peer applications can look like when they are not routed through a central server, the platform provides the runtime, the schema, and the transport. What is built on top of them is a matter of what the developer chooses to create.
The Hardening Stack
AM·OS is hardened at five layers. No single layer is sufficient on its own, and the combination is what places the platform where it sits.
1. Kernel build-time hardening
The kernel is compiled with the KSPP-recommended configuration set. This includes base address and memory layout randomisation, virtually mapped stacks, strict read-only kernel and module memory, hardened user copies, slab freelist randomisation and hardening, initialisation of stack and heap memory to zero, the full CPU mitigation set for Spectre, MDS, TAA, Retbleed, SRBDS and related classes, and lockdown in confidentiality mode. Intel CET (IBT and Shadow Stack) is enabled. Module signing is enforced: every kernel module must carry a valid signature or it will not load.
2. Userspace binary hardening
Every binary in every package is compiled with position-independent code, full RELRO, stack canaries, FORTIFY source checks, non-executable stack, and CET where the architecture supports it. This is verified by an automated audit that walks the production tree, extracts each package, and inspects every ELF object against the OpenSSF-recommended mitigation set. The audit produces a per-binary report and a machine-readable exception table, with a specific and reproducible reason for every case where a check cannot fire.
3. Package authenticity and integrity
Two independent signing mechanisms are in place. Every .txz package is signed with a GPG key, and the installer verifies those signatures on install. Separately, every ELF object inside every package is signed with an IMA signature at build time, and that signature travels with the file through installation.
4. Runtime code integrity
The kernel loads an IMA signing certificate into the .ima keyring at boot. An appraisal policy then requires a valid signature on every executable executed via BPRM_CHECK and on every shared library mapped for execution via MMAP_CHECK. A file without a valid signature cannot run. This closes the loop: even an attacker who gains root cannot replace a signed binary with a trojaned version and execute it, because the kernel will refuse.
5. Per-process network isolation
Network access is controlled per cgroup, not per user or per service. The web server's Java process runs in a cgroup that cannot reach any non-loopback address. Its own Tor daemon runs in a child cgroup with unconditional outbound access. The system Tor, when running, is in a third cgroup with its own distinct rules. Everything else falls through to a default DROP. This layer is described in the next section.
The Network Isolation Model
Where ADDNS handles inbound reachability, the isolation model handles outbound control. Together they define what a hosted service can receive and what it can send.
The three modes
AM·OS runs in one of three network modes at any time. The mode determines what the system as a whole may reach on the network. Individual processes are further constrained by cgroup membership.
Strict
The boot-time default. Only the web server's own Tor daemon may reach the network. Every other outbound connection is dropped. System Tor is not running. Loopback, DHCP renewal, and inbound SSH from the configured management host are the only exceptions.
Open
Time-bounded, default 300 seconds, auto-reverting to strict. System Tor is started in its own cgroup and the machine's outbound TCP and DNS are redirected through it via NAT. Every process that is not explicitly exempted has its traffic routed through Tor, transparently.
Clearnet
Time-bounded, default 300 seconds, auto-reverting to strict. System Tor is stopped and outbound goes directly to the public internet. A warning banner is printed on entry, logged to syslog, and broadcast to every logged-in user via wall. The web server's own Tor is unaffected and the hidden service remains reachable.
The three cgroups
Inside every mode, three cgroups receive special treatment. The rules that match them are hierarchical, and the specific rule for the web server's Tor child cgroup is always placed before the general rule for its parent, because cgroup v2 path matching uses descendant semantics.
| Cgroup | Contents | Network policy |
|---|---|---|
/annode/tor |
The web server's Tor daemon, relocated here by a watcher in rc.annode the moment it appears. |
Direct outbound, unconditional, in every mode. This is what keeps the hidden service alive across mode transitions. |
/annode |
The Java process, its su wrapper, and any helper processes. |
Non-loopback traffic dropped in every mode. The JVM can only reach 127.0.0.1, which is where the web server's Tor SocksPort listens. |
/system-tor |
The system Tor, only present in open mode. | In open mode, its own outbound is exempted from the NAT redirect rules, otherwise its circuits would be rewritten into its own TransPort. |
Properties of the design
The application process cannot reach the clearnet, by construction. The web server's Java process has exactly one path to the network: its own Tor SocksPort on loopback. If the JVM is compromised by a remote exploit, the attacker inherits a process that can only talk to loopback. No configuration error, no forgotten rule, and no operator mistake can grant it direct internet access, because no rule exists that would.
The hidden service stays reachable across mode transitions. When the operator enters open or clearnet mode to install updates or run diagnostics, the web server continues to publish its onion address and serve requests. Mode changes affect the system's outbound traffic, not the node's inbound reachability.
Clearnet outbound is bounded, announced, and requires deliberate action. The system cannot enter clearnet mode on its own. A timer reverts to strict after the configured interval. Every logged-in user receives a warning via wall at the moment of transition. Syslog records the entry with a timestamp.
Boot-time enforcement
Strict mode is applied by rc.firewall, invoked from rc.inet1 the moment the network interface is configured. No daemon starts before this. SSH, MariaDB, and every other service come up after the firewall rules are in place. The system is in lockdown from the first packet.
Most hardened servers use a host firewall with per-service or per-port rules. AM·OS uses per-process network identity, expressed through the cgroup hierarchy, combined with a mode system that changes the machine's default network posture. The answer to "can process X reach the internet" is determined by which cgroup it lives in, and the answer is enforced the same way in every mode and on every deployment. Combined with the ADDNS layer, this gives the platform both inbound reachability and outbound control, each enforced at the kernel level.
AM·OS in the field
The following table compares AM·OS against the most prominent hardened Linux projects, grouped by architectural focus. The comparison is not a ranking. Each project targets a different threat model, and several are complementary to AM·OS rather than competitors.
| Distribution | Primary threat model | Core architecture | Key mechanisms |
|---|---|---|---|
| AM·OS | Self-hosted service compromise, code replacement, unintended network egress | Integrity-verified execution with per-process network isolation and clearnet-reachable hidden services | Kernel and userspace hardening, IMA appraisal, signed packages, AppArmor, strict sysctl profile, per-cgroup network policy with three modes, ADDNS integration |
| RHEL 9+ / Oracle Linux 9+ | Enterprise server compromise, supply chain attacks, regulatory compliance | Certified enterprise platform with integrity verification | SELinux, IMA appraisal with per-file signatures, ima-setup tooling, Secure Boot integration, systemd policy loading |
| Qubes OS | Desktop compromise, malicious documents, advanced persistent threats | Security by compartmentalization using the Xen hypervisor | Type-1 hypervisor, VM isolation per application or domain, disposable VMs, secure network routing via Whonix |
| Whonix | Network anonymity, IP leaks from compromised applications | Security by isolation using a Gateway and Workstation split | Forced Tor routing, two-VM isolation, stream isolation |
| Tails | Leaving no trace on the host machine, censorship circumvention | Amnesic live system | Live USB, no persistent storage by default, all traffic through Tor, MAC address spoofing |
| Kicksecure | Desktop malware, targeted attacks, forensic analysis | Security by default with system hardening | KSPP-hardened kernel, AppArmor, strict sysctl, user account isolation, live mode |
| secureblue | Desktop malware, browser exploits, general attack surface reduction | Immutable and atomic OS with secure defaults | Read-only root filesystem, Wayland-only, KSPP-hardened kernel, SELinux, image-based updates |
| Hardened Gentoo | Custom minimal attack surface for expert users | Source-based with compile-time hardening | Custom hardened kernel patchsets, PIE and SSP and RELRO across the tree, minimal package set, USE flag control |
Comparative notes
AM·OS and Qubes OS solve different problems. Qubes isolates a known-compromised application from the rest of the system using hypervisor-level compartmentalization. AM·OS ensures that the code executing on a single system is exactly the code the operator approved, and that each process has only the network access it needs. The two are complementary. Running AM·OS as a service VM inside Qubes would combine both guarantees.
AM·OS and Whonix share the Tor focus but differ in mechanism. Whonix uses two virtual machines, a Gateway that routes everything through Tor and a Workstation that cannot reach the network directly. AM·OS achieves a comparable isolation outcome on a single machine, using cgroups and iptables, and additionally provides a clearnet-reachable path to the hidden service via ADDNS. Whonix is designed for interactive desktop use. AM·OS is designed for a persistent service.
AM·OS and Kicksecure or secureblue serve different audiences. Those are general-purpose hardened desktops. Their goal is to be a secure daily driver across a wide range of activities. AM·OS is a specialized self-hosting platform. It goes deeper on runtime integrity, network isolation, and hidden-service reachability for a narrow workload.
AM·OS and Hardened Gentoo share the closest philosophy. Both are built from source, both apply hardening at compile time across the entire tree, and both assume a technically competent operator. The distinguishing features of AM·OS are IMA appraisal as a runtime enforcement mechanism, per-cgroup network policy, and ADDNS-based clearnet reachability for hidden services.
Deep Dive into AM·OS and RHEL IMA
Red Hat Enterprise Linux is the distribution most commonly associated with IMA in the enterprise space, and its implementation is the closest analog to what AM·OS provides. Both solve the same problem, and they arrive at similar designs. The differences are in packaging and control.
| Aspect | RHEL 9+ | AM·OS |
|---|---|---|
| Per-file package signatures | Yes. Every file in every package is signed and stored in security.ima. |
Yes. Every ELF object is signed at build time by a forked makepkg and carried through installation. |
| Appraisal scope | Executables and shared libraries, via a sample policy shipped by Red Hat. | Executables and shared libraries, via a custom policy written for this workload. |
| Policy loading | systemd reads /etc/ima/ima-policy during boot. |
Policy injected into the initramfs and loaded before switch_root. |
| Tooling | ima-setup configures keys, policy, and dracut integration in one step. |
Custom scripts in the installer and build orchestration. No vendor tooling. |
| Key management | Red Hat provisions the trust hierarchy and manages key rotation. | AM·OS generates a two-tier hierarchy at build time: the module signing key as the CA, and the IMA signing key as the leaf. Both are shipped with the image. The operator can regenerate the full chain and rebuild under their own keys. |
| Secure Boot integration | Deep. Under RHEL 10, only IMA policies signed by a trusted key can load when Secure Boot is active. | Deliberately excluded. AM·OS will not participate in the Secure Boot chain, now or at any future point. |
| Policy flexibility | Fixed to Red Hat's sample unless the operator writes their own. | Fully custom. The policy is tuned to the exact set of executables and libraries the system runs. |
AM·OS is architecturally equivalent to RHEL for the integrity layer, with three practical differences. It is more customisable, because nothing in the chain is hidden. The keys, the policy, and the build scripts are all in the source tree, and any of them can be replaced. It is more transparent, because every step is a script the operator can read. And it does not participate in the Secure Boot chain, now or at any future point. This is a deliberate, permanent design decision, not a missing feature awaiting implementation. Secure Boot requires the operator to obtain signing authority from a third party, typically a hardware vendor or a platform vendor, and to accept that party's key as a root of trust on their own machine. A platform whose premise is that no third party stands between the operator and their own infrastructure cannot, by definition, require one to approve the bootloader. The integrity guarantee on AM·OS is anchored to keys the operator generates and controls, not to keys issued by an outside authority. That is the point of the platform, and it is the reason Secure Boot will never be part of the chain.
Kernel Hardening Audit
The kernel configuration was audited against the KSPP-recommended settings and the profiles tracked by the kernel-hardening-checker tool. The tool evaluates each option against multiple reference profiles, including KSPP, CLIP OS, grsecurity, and lockdown.
Every one of the 21 flagged items was investigated individually. None represent an unfixed weakness. They fall into five categories.
| Category | Explanation |
|---|---|
| False positives | The checker expects an exact match, and in two cases the value in use is stricter than the recommendation. DEFAULT_MMAP_MIN_ADDR is set to a higher value than KSPP requires. LSM_MMAP_MIN_ADDR is an obsolete symbol that no longer exists. |
| Debug options | Options such as DEBUG_VIRTUAL, DEBUG_SG, and DEBUG_NOTIFIERS are developer sanity checks with runtime cost. They are not security features and are not shipped by enterprise kernels. |
| Toolchain requirements | The CFI options require building the kernel with Clang. AM·OS builds with GCC, so the equivalent protection is provided by hardware CET instead. |
| Version-specific | RANDOM_KMALLOC_CACHES is not present in the 7.2.9 Kconfig. It will be considered when the kernel version supports it. |
| Documented exceptions | Options such as MODULES, FB, VT, AIO, RSEQ, KALLSYMS, and BPF_SYSCALL are required by the workload or by system components. Each has an explicit justification. For example, modules are enabled but every module is signed and MODULE_SIG_FORCE is set, which satisfies KSPP's own fallback recommendation. |
On the meaning of "KSPP-hardened." There is no certification called a KSPP kernel. KSPP publishes recommendations, not a compliance standard. The accurate description of AM·OS is: a kernel built with the KSPP-recommended hardening set, with documented exceptions for production requirements. This is the same standard RHEL, Amazon Linux, and other production-oriented hardened kernels are held to.
Binary Hardening Audit
Every ELF object in every package in the production tree is inspected against the OpenSSF-recommended binary mitigation set by an automated audit. The audit extracts each package, walks every executable and shared library, and produces a per-binary report that records the state of each mitigation together with the evidence that determines it. Where a check cannot fire for a reason the audit cannot detect on its own, the case is registered in a separate exception table with a specific, reproducible justification.
The six checks
| Mitigation | What it means |
|---|---|
| PIE | Position-independent executable. The binary can be loaded at any address, so its memory layout is randomised by ASLR. |
| Full RELRO | The global offset table is remapped read-only after dynamic linking, so it cannot be overwritten by a memory-corruption bug. |
| Stack canary | Stack buffer overflows are detected before the function returns, and the process aborts rather than continuing with corrupted control flow. |
| FORTIFY | Compile-time and runtime checks on string and memory operations that have known unsafe signatures. |
| NX stack | The stack is mapped without execute permission, so injected shellcode cannot run from stack memory. |
| CET | Intel Control-flow Enforcement Technology. Hardware-enforced forward-edge protection (IBT) and backward-edge protection (Shadow Stack). |
Interpreting the results
Each check on each binary returns one of three states. A package-level aggregate adds a fourth for the case where a package contains a mix of results.
- Present means the binary carries the mitigation. For PIE, RELRO, NX, and CET this is a property that either is or is not in the ELF header. For canary and FORTIFY it is a symbol reference, or a pattern in the disassembled code, that establishes the check is compiled in.
- Not applicable means there is no code in the binary that could carry the mitigation. A shared library with no C stack frames has no canary because there is nothing to canary. A firmware blob built for a non-x86 architecture has no CET because CET does not exist on that architecture. A tiny stub function that is too small for a stack buffer has no canary because the compiler correctly emits none. In every case, the absent check is not a gap because there is no code where the check would go.
- Absent, unexplained is the only state that counts as a failure. The binary has code where the check should apply, and the check is missing. This is what the audit exists to find.
- Audited exception appears only at the package level, when a package contains at least one binary matched against the exception table and no binary has an unexplained absence. It indicates that the package passes, and that its pass rests on a specific documented reason rather than on the check being naturally present.
A binary passes when no check returns absent. A package passes when no binary in it has an absent result. Not applicable is a pass, because there is nothing to harden. An audited exception is a pass, because the reason is registered, reproducible, and verified against the binary itself.
The exception tables
Two exception tables are recognised by the audit. Each entry names a specific package and binary, and each carries a reason that must be verifiable from the source or from the binary. The reason is the audit trail; an entry that is not specific enough to be checked does not belong in the table.
| Table | Affects | Meaning |
|---|---|---|
| FORTIFY exception | Marks F as N/A for a specific binary. | A genuine not-applicable case. The binary was compiled with the FORTIFY flags, and the compiler correctly declined to emit a __*_chk wrapper because the destination size is not visible in the translation unit, or because the call is provably safe and was folded away. The audit's automatic check cannot detect either condition, so the case is registered explicitly with the source-level or disassembly-level evidence that confirms it. |
| CET accepted gap | Marks T as an accepted gap for a specific binary or kernel module. | A real gap: the binary does not carry the IBT property in its .note.gnu.property section. The gap is accepted because the toolchain in use provides no mechanism to emit the property, and the affected code is removed from the running system by one of two mitigations. For kernel modules that link assembly inputs, the module is blacklisted at install and never loads. For userspace binaries from a toolchain that does not emit the required instruction, the package is excluded from the ISO. |
Results
Across 7,032 binaries in 249 ELF-bearing packages, every one passes. No binary in the shipping tree reaches the CPU without PIE, RELRO, canary where applicable, non-executable stack, and CET where the toolchain supports it.
| Category | Count | Resolution |
|---|---|---|
| Binaries with no real gaps | 6,985 | Every check present in the binary, or absent for a reason the audit classifies as not applicable. Includes 64 binaries where FORTIFY was correctly omitted by the compiler. |
| Binaries with accepted gaps | 47 | Real gaps, each registered in AUDIT.TXT with a specific reason. Broken down by exception type below. |
| Binaries with unexplained gaps | 0 | None. The audit found no binary with a mitigation missing for an unregistered reason. |
| Exception type | Count | Note |
|---|---|---|
| FORTIFY not applicable, compiler folded the check | 64 | The compiler correctly declined to emit a __*_chk wrapper because the destination size is not visible in the translation unit, or because the count equals the destination size and the check is provably false. Not a gap. |
| CANARY accepted gap | 2 | Real gap, accepted, reason in AUDIT.TXT. |
| CET accepted gap, kernel module with assembly input | 20 | The GCC toolchain emits no .note.gnu.property IBT bit for .S inputs. Module blacklisted at install and never loads. |
CET accepted gap, userspace binary from toolchain without endbr64 |
26 | The Go toolchain emits neither endbr64 landing pads nor the IBT property. Package excluded from the ISO, available from the repository on request. |
Overlap: libstd.so (Rust) appears in both the CANARY and CET accepted-gap categories. Category entries therefore total 48, but unique binaries with accepted gaps total 47.
Scope of the audit
Every binary in the ISO reaches the CPU with the full mitigation set the platform targets, or the binary has no code where the mitigation would apply, or the binary is one of three accepted categories with a deterministic mitigation that removes it from the running system. The exception table is not a way to hide a gap. It is a way to record, with evidence, the small number of cases where the check cannot fire, and to prove that each case has been investigated rather than overlooked.
The audit is reproducible. Anyone with access to the production tree can rerun the script and get the same result. The evidence for each exception is recorded in the same repository, with specific file and line references, disassembly excerpts, and in most cases a companion replica that demonstrates the compiler behaviour under the exact build flags used for the shipped binary.
The Wider IMA Landscape
The IMA landscape is uneven. Most distributions compile IMA into the kernel but leave appraisal disabled. Only a small number ship it in a state where it can be enabled through a documented step. Two independent questions determine where a distribution sits. The first is whether appraisal is enforced at runtime. The second is who manages the trust hierarchy. On the first, AM·OS is ahead of RHEL: appraisal is enforced from the first userspace process, with nothing to enable, no ima-setup step, and no reboot cycle. RHEL ships with appraisal off by default and requires the operator to enable it. The AM·OS default can be disabled by boot flag if the operator chooses to, the same way any other policy on the platform can be adjusted. On the second, RHEL leads in managed convenience: Red Hat provisions the trust hierarchy and manages key rotation, so the operator never generates a key. On AM·OS the project generates the same hierarchy at build time and ships it with the image. The operator has the option to regenerate the full chain under their own keys and rebuild.
The verdict labels describe each distribution's actual position rather than forcing both into a shared template. "Production" means the platform is deployable as it stands. "Enforced" (AM·OS) and "turnkey" (RHEL) describe the state of the mechanism: on AM·OS, appraisal is running from the first userspace process; on RHEL, the vendor has done the integration work and the operator activates it. "Opt-out" (AM·OS) and "opt-in" (RHEL) describe the default: AM·OS ships with appraisal on and the operator can disable it by boot flag; RHEL ships with appraisal off and the operator must enable it. The labels are not a ranking of security. They describe what each distribution ships and what remains for the operator to do.
| Distribution | Support level | Notes |
|---|---|---|
| AM·OS | Production, enforced, opt-out | Per-file signatures, custom policy tuned to the workload, initramfs-based policy loading, two-tier key hierarchy generated by the project and shipped with the image. The operator can regenerate under their own keys. Appraisal enforced from first userspace process, enabled by default and disableable by boot flag. |
| RHEL 9+, CentOS Stream | Production, turnkey, opt-in | Per-file signatures, ima-setup tool, systemd policy loading, Secure Boot integration. Appraisal off by default; operator must enable it. |
| Oracle Linux 9+ | Production, turnkey, opt-in | Uses the Unbreakable Enterprise Kernel with per-file signatures and IMA appraisal for executables. Appraisal off by default. |
| Fedora | Built in, not enabled | IMA appraisal support is compiled in but not activated by default. Requires boot parameters to enable. |
| Ubuntu 22.04+ | Built in, not enabled | IMA is present in the default kernel but disabled in policy. Manual configuration required. |
| Debian | Built in, not enabled | IMA and EVM are present in dracut and the kernel, but appraisal is not active by default. |
| openSUSE / SUSE Linux Enterprise | Attestation focus | Primarily used with Keylime for remote attestation. Local enforcement is not the default. |
| Gentoo | Project-based | An Integrity project exists for IMA and EVM integration, but it is not enabled by default. |
| Alpine, Arch | Tools only | Userspace tools are packaged, but no default kernel policy or turnkey setup is provided. |
IMA is present in the kernel of almost every major distribution, but a complete implementation with per-file signatures and a working trust chain is rare. RHEL and Oracle Linux lead in managed deployment: they will provision the keys and enable the mechanism for you, and both document how to replace the vendor chain with a custom one. Oracle named its kernel Unbreakable. By default, that kernel, like RHEL's, will run whatever binary is placed on disk. AM·OS's will not, at any privilege level, and every script that enforces that is in the source tree. AM·OS is the only system in this table where appraisal is enforced by default rather than enabled by the operator. The chain that establishes it is generated at build time from scripts in the source tree, and an operator who wants to regenerate it under their own keys can do so and rebuild.
Enforcement boundaries
The integrity and isolation model is deliberately narrow. It is worth being explicit about the boundaries, because both IMA and per-process firewalls are often described in terms that overstate what they protect against.
In scope
- Every executable that runs must carry a valid signature from the IMA key trusted by the platform. An unsigned or tampered binary cannot execute.
- Every shared library mapped for execution must carry the same signature. This closes the shared-library injection path.
- The trust anchor is loaded into the kernel at boot from the initramfs, before any userspace process runs. An attacker cannot replace it at runtime.
- The IMA policy itself is loaded from the initramfs and cannot be replaced without a reboot. Once loaded, it is immutable.
- Network access is determined by cgroup membership. A process cannot change its cgroup without the appropriate privilege, and the cgroup of every relevant process is fixed at service start.
- Clearnet outbound mode requires an explicit operator command. It cannot be entered by any other means, and it reverts to strict on a timer.
- Kernel modules must be signed. An unsigned module cannot be loaded, even by root.
Out of scope
- Configuration files, log files, databases, and other mutable data are not appraised. They change at runtime and cannot carry stable signatures.
- Scripts interpreted by a signed interpreter are not themselves appraised. The interpreter is checked; the script content is not.
- Offline tampering by an attacker with physical access to the disk is out of scope. IMA protects the running system, not the disk at rest. That is the role of LUKS.
- Firmware and boot loader integrity is not chained. Secure Boot is deliberately excluded from the trust path and will remain so.
- The Tor traffic itself is not verified. AM·OS controls which processes may reach the network and under what conditions, not what they send once they are permitted.
This scope is deliberate. Appraising data files would require re-signing them on every write, which is impractical and would break every service that maintains its own state. The correct defenses for configuration tampering are file permissions, mandatory access control, and audit logging. IMA's job is narrower: ensuring that the code reaching the CPU is the code the operator approved. The network isolation layer's job is equally narrow: ensuring that a process which should not reach the network cannot, regardless of what code it is running.
Summary Assessment
AM·OS is not a general-purpose distribution. It is a privacy and security platform for self-hosting web services, deployable as a virtual machine, on home hardware, or on a server, with the same integrity and isolation guarantees in every context. Within that scope, four claims can be made without overstatement.
- It removes the exposure of self-hosting from home. A machine on a residential connection can serve a public web service without publishing its address, without opening a port, and without making the household behind it a target. The ADDNS layer translates between the clearnet request and the Tor circuit, and the node's IP address never appears in the protocol.
- It runs the same operating system in every deployment context. VirtualBox, QEMU, bare metal on BIOS or EFI, home connection or datacenter. The networking model does not depend on a public address, so a node behind carrier-grade NAT behaves identically to a node with a routable IP.
- Its integrity model is architecturally equivalent to RHEL 9 and Oracle Linux 9. Per-file signatures, executable-focused appraisal, a two-tier key hierarchy, and boot-time policy loading. The differences are in packaging and in who can regenerate the chain, not in the guarantee itself. Every script that generates the keys, signs the packages, and loads the policy is in the source tree, and the operator can rebuild the entire chain under their own keys without changing any code.
- Its network isolation model has no direct commercial equivalent. Per-cgroup network identity, three modes with automatic reversion, and a deliberate design in which a hosted application's only path to the network is through its own Tor. This is enforced the same way in every mode and on every deployment.
The areas where the platform is behind are identified and understood: Secure Boot integration, TPM-based attestation, and the packaged tooling that enterprise distributions provide. Each is a known gap with a known path forward. None of them undermine the current security posture.
AM·OS Ghost Net Edition is a system whose integrity guarantees, network isolation model, and clearnet-reachable hidden-service architecture are matched by very few platforms, and whose operator has visibility into every layer of the chain. It makes self-hosting a reasonable proposition for anyone with a computer, without asking them to expose where that computer lives.