@holoscript/holosystem 0.2.3 → 0.2.5

package/README.md

@@ -511,6 +511,30 @@ AMD64 host, `qemu-system-x86_64.exe`, q35, 128 MiB, one CPU, and exactly two
 launches. Plans cannot provide a command, argument, environment variable,
 device, network, firmware, monitor, display, or fallback setting.
 
+`vm-launch-whpx-sandboxed` is a third, separately named vocabulary. It retains
+the explicit WHPX contract and additionally launches QEMU through the measured
+Windows helper shipped in this package. The helper creates a
+`CreateRestrictedToken(DISABLE_MAX_PRIVILEGE)` filtered token, lowers it to low
+integrity, admits at most the single Windows pass-through privilege, creates
+the process suspended with an explicit three-handle allowlist, assigns it to a
+kill-on-close Job Object with one-process, memory, and UI restrictions, and
+only then resumes it. A private low-integrity temporary directory is the only
+intended writable launch location.
+
+`vm-launch-whpx-appcontainer` is a fourth, separately named vocabulary. It
+retains those restricted-token and Job controls, gives an ephemeral Windows
+AppContainer identity zero capabilities, grants that identity only read/execute
+access to the measured launch snapshot and modify access to its private temp
+directory, and requires file-read plus loopback-connect attack canaries to fail
+before either WHPX launch begins. The plan cannot name a capability, path,
+command, network mode, or fallback.
+
+`vm-launch-appcontainer` uses the same zero-capability boundary with QEMU TCG.
+It fixes the translation buffer at 64 MiB so the one-process 512 MiB Job limit
+remains effective. This is the fully confined adapter proven on the validated
+Windows host: it proves the machine VM and host file/network boundary, but sets
+`hardwareBacked: false` and keeps hardware acceleration missing.
+
 First measure the complete caller-owned QEMU runtime closure and both guest
 artifacts:
 
@@ -567,6 +591,44 @@ arguments for the WHPX schema. WHPX requires the Windows Hypervisor Platform
 API exposed to QEMU; see the [QEMU WHPX documentation](https://www.qemu.org/docs/master/system/whpx.html)
 and [Microsoft's Windows Hypervisor Platform API overview](https://learn.microsoft.com/en-us/virtualization/api/).
 
+For the sandboxed adapter, use schema
+`holoscript.holosystem.whpx-sandboxed-vm-launch-plan.v1`, add the following
+closed field, and call `vm-launch-whpx-sandboxed`:
+
+```json
+{
+  "sandbox": {
+    "kind": "windows-low-integrity-job-v1",
+    "launcherDigest": "sha256:<HOLOSYSTEM_WINDOWS_SANDBOX_LAUNCHER_DIGEST>"
+  }
+}
+```
+
+The exported `HOLOSYSTEM_WINDOWS_SANDBOX_LAUNCHER_DIGEST` is the digest of the
+package's audited launcher binary. A plan with another digest is blocked before
+process creation. The launcher source and local rebuild recipe are shipped in
+`native/windows-sandbox`; the measured binary is shipped in
+`native/windows-x64`.
+
+For the AppContainer adapter, use schema
+`holoscript.holosystem.whpx-appcontainer-vm-launch-plan.v1`, use the same
+launcher digest with sandbox kind `windows-appcontainer-deny-v1`, and call
+`vm-launch-whpx-appcontainer`. The launcher creates and deletes a fresh profile
+for each launch. Its closed receipt protocol must prove the child AppContainer
+SID, zero capabilities, low-integrity filtered token, snapshot/temp grants,
+access-denied (`5`) for a protected caller-readable file, plus either explicit
+WSA access-denied (`10013`) or a bounded WFP-style packet-drop timeout (`10060`)
+with no accepted live loopback connection. Any missing or changed observation
+blocks the receipt.
+
+Use schema `holoscript.holosystem.appcontainer-vm-launch-plan.v1`, target
+accelerator `tcg`, the same two sandbox digests, and command
+`vm-launch-appcontainer` for the software-emulated confined lane. On the
+validated Windows 11 host, the WHPX AppContainer form fails closed because
+Windows returns `0x80070005` when zero-capability QEMU initializes WHPX. The
+package does not merge that result with the separately proven hardware-backed
+low-integrity WHPX receipt.
+
 The runner creates a private snapshot and remeasures the complete QEMU closure,
 kernel, and initramfs before and after each launch. It then generates QEMU
 arguments that disable user configuration, default devices, networking, USB,
@@ -583,21 +645,49 @@ A verified TCG receipt includes `machine-vm-launch`,
 `hardwareBacked: false`, and leaves hardware acceleration missing. A verified
 WHPX receipt additionally includes `hardware-hypervisor-acceleration` and sets
 `hardwareBacked: true` only after two explicit WHPX launches succeed. Both
-adapters leave `host-process-isolation` missing: QEMU still has the ambient
+ambient adapters leave `host-process-isolation` missing: QEMU still has the ambient
 rights of the Windows process. Receipts therefore expose
 `isolation.hostProcess: "ambient-windows-process"` and
 `isolation.verified: false` even when WHPX acceleration is verified. Neither
-receipt proves an IOMMU, measured boot, firmware authenticity, confidential
-memory, or side-channel resistance. The
+ambient adapter receipt proves an IOMMU, measured boot, firmware authenticity,
+confidential memory, or side-channel resistance.
+
+A verified `vm-launch-whpx-sandboxed` receipt includes
+`host-process-isolation` only for the declared integrity, privilege,
+inherited-handle, lifetime, process-count, memory, and UI scope. It deliberately
+leaves `host-filesystem-confidentiality` and `host-network-isolation` missing:
+low integrity prevents writes up to medium-integrity objects but does not
+prevent reads, and the filtered token is not an AppContainer network capability
+boundary. The sandboxed receipt also does not prove the broader hardware and
+firmware properties named above. The
 exact claims are in the [VM launch threat model](./docs/vm-launch-threat-model.md).
 
+A verified `vm-launch-whpx-appcontainer` receipt additionally includes
+`host-filesystem-confidentiality` and `host-network-isolation` for the tested
+zero-capability AppContainer boundary. Those are scoped claims: they do not
+establish QEMU provenance, host-kernel correctness, IOMMU separation, measured
+boot, firmware authenticity, crash-dump custody, confidential memory, or
+side-channel resistance.
+
+A verified `vm-launch-appcontainer` receipt includes the same process,
+filesystem, and network layers while leaving
+`hardware-hypervisor-acceleration` missing. Receipts describe one executed
+boundary, not the union of properties observed in different launches.
+
 ```js
 import {
   inspectVmExecutor,
+  inspectAppContainerVmLaunchPlan,
   inspectVmLaunchAsset,
   inspectVmLaunchPlan,
+  inspectWindowsVmSandboxLauncher,
+  inspectWhpxAppContainerVmLaunchPlan,
+  inspectWhpxSandboxedVmLaunchPlan,
   inspectWhpxVmLaunchPlan,
   runVmLaunch,
+  runAppContainerVmLaunch,
+  runWhpxAppContainerVmLaunch,
+  runWhpxSandboxedVmLaunch,
   runWhpxVmLaunch,
 } from '@holoscript/holosystem';
 ```

package/bin/holosystem.mjs

@@ -14,7 +14,10 @@ import {
   inspectVmExecutor,
   inspectVmLaunchAsset,
   runNativeBuild,
+  runAppContainerVmLaunch,
   runVmLaunch,
+  runWhpxAppContainerVmLaunch,
+  runWhpxSandboxedVmLaunch,
   runWhpxVmLaunch,
 } from '../src/index.mjs';
 
@@ -34,7 +37,10 @@ Usage:
   holosystem vm-executor --runtime <directory> [--json]
   holosystem vm-asset --kind <kernel|initrd> --file <file> [--json]
   holosystem vm-launch --plan <file> --runtime <directory> --kernel <file> --initrd <file> [--output <receipt>] [--force] [--json]
+  holosystem vm-launch-appcontainer --plan <file> --runtime <directory> --kernel <file> --initrd <file> [--output <receipt>] [--force] [--json]
   holosystem vm-launch-whpx --plan <file> --runtime <directory> --kernel <file> --initrd <file> [--output <receipt>] [--force] [--json]
+  holosystem vm-launch-whpx-sandboxed --plan <file> --runtime <directory> --kernel <file> --initrd <file> [--output <receipt>] [--force] [--json]
+  holosystem vm-launch-whpx-appcontainer --plan <file> --runtime <directory> --kernel <file> --initrd <file> [--output <receipt>] [--force] [--json]
   holosystem substrate --input <file> [--output <file>] [--force] [--json]
   holosystem --help
   holosystem --version
@@ -701,11 +707,26 @@ if (!command || command === '--help' || command === '-h' || command === 'help')
   runVmAsset(argv.slice(1));
 } else if (command === 'vm-launch') {
   runVmLaunchCommand(argv.slice(1));
+} else if (command === 'vm-launch-appcontainer') {
+  runVmLaunchCommand(argv.slice(1), {
+    launcher: runAppContainerVmLaunch,
+    commandName: 'vm-launch-appcontainer',
+  });
 } else if (command === 'vm-launch-whpx') {
   runVmLaunchCommand(argv.slice(1), {
     launcher: runWhpxVmLaunch,
     commandName: 'vm-launch-whpx',
   });
+} else if (command === 'vm-launch-whpx-sandboxed') {
+  runVmLaunchCommand(argv.slice(1), {
+    launcher: runWhpxSandboxedVmLaunch,
+    commandName: 'vm-launch-whpx-sandboxed',
+  });
+} else if (command === 'vm-launch-whpx-appcontainer') {
+  runVmLaunchCommand(argv.slice(1), {
+    launcher: runWhpxAppContainerVmLaunch,
+    commandName: 'vm-launch-whpx-appcontainer',
+  });
 } else if (command === 'substrate') {
   runSubstrate(argv.slice(1));
 } else {

package/docs/vm-launch-threat-model.md

@@ -17,6 +17,35 @@ Windows Hypervisor Platform adapter for those launches; it does not prove host
 process isolation. QEMU retains the ambient rights of its Windows process in
 both adapters.
 
+`vm-launch-whpx-sandboxed` is a separate schema and receipt. It runs the same
+measured WHPX launch behind a measured native Windows launcher that creates a
+filtered token with `DISABLE_MAX_PRIVILEGE`, sets low mandatory integrity,
+verifies at most the single pass-through privilege remains enabled, creates
+QEMU suspended with only NUL/stdout/stderr handles inherited, assigns QEMU to a
+Job Object before resume, and applies kill-on-close, one-process, 512 MiB, and
+full Job UI restrictions. Its `host-process-isolation` claim is limited to
+those controls. It is not an AppContainer and does not claim host filesystem
+confidentiality or host network isolation.
+
+`vm-launch-whpx-appcontainer` is another separate schema and receipt. It adds
+an ephemeral zero-capability AppContainer identity to the same filtered,
+low-integrity token and pre-resume Job boundary. The identity receives inherited
+read/execute access to the private measured snapshot and modify access only to
+the private temp directory. Before QEMU starts, the launcher runs an
+AppContainer child under the same token and verifies that it cannot read a
+caller-readable protected sentinel or connect to a live loopback listener. The
+receipt claims filesystem confidentiality and network isolation only when the
+token identity, zero capability count, exact denial errors, and both WHPX boots
+all verify.
+
+`vm-launch-appcontainer` applies the same boundary to TCG with a fixed 64 MiB
+translation buffer. It can claim process, filesystem, and network isolation
+after two deterministic boots, but it cannot claim hardware acceleration. On
+the validated Windows 11 host, zero-capability QEMU receives access denied
+(`0x80070005`) while initializing WHPX. That negative result is preserved as a
+blocked WHPX AppContainer receipt; it is never combined with the verified TCG
+AppContainer receipt or the separately verified low-integrity WHPX receipt.
+
 ## Protected assets and trust boundaries
 
 The protected inputs are the declarative plan, the complete caller-owned QEMU
@@ -39,20 +68,27 @@ than implied away by a successful boot.
 
 ## Adversary specifications
 
-| Adversary action                                                                                     | Required result                                                            | Receipt or test evidence                                   |
-| ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ---------------------------------------------------------- |
-| Add a shell command, argument vector, environment field, device, network mode, or unknown plan field | Reject before process launch                                               | `vm-launch-field-unknown`; closed-vocabulary test          |
-| Put WHPX in a TCG plan, TCG in a WHPX plan, or request a fallback                                    | Reject rather than downgrade, cross-route, or overclaim                    | Separate schemas; accelerator/unknown-field tests          |
-| Replace any QEMU executable, DLL, firmware file, kernel, or initramfs before measurement             | Reject before process launch                                               | Runtime, binary, kernel, and initrd digest mismatch issues |
-| Replace measured files while the launch snapshot is being created                                    | Reject the snapshot                                                        | Runtime, kernel, and initrd snapshot mismatch issues       |
-| Replace caller-owned files after the first launch                                                    | Second launch still uses the same private snapshot                         | Private-snapshot substitution test                         |
-| Persistently self-modify the private runtime or guest artifacts during a launch                      | Reject on post-launch remeasurement                                        | Private-snapshot drift test                                |
-| Inject QEMU behavior through inherited environment variables or user configuration                   | Launch with a minimal environment and `-no-user-config`                    | Generated-argv test                                        |
-| Obtain implicit host devices or a communication channel                                              | Start with `-nodefaults`, `-nic none`, USB off, no display, and no monitor | Generated-argv test                                        |
-| Forge the guest signal, use the wrong exit path, or change adapter diagnostics                       | Reject the receipt and retain no raw output                                | Console, exit-code, and diagnostic-digest tests            |
-| Make clean launches observably disagree                                                              | Reject deterministic coverage                                              | `vm-launch-nondeterministic`                               |
-| Inject a fake process runner through the public API                                                  | Ignore it and execute only the bound process implementation                | Public process-runner injection test                       |
-| Put an operational path or guest output in the receipt                                               | Withhold it; report only digest and byte count                             | Receipt disclosure assertions                              |
+| Adversary action                                                                                     | Required result                                                             | Receipt or test evidence                                   |
+| ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------- |
+| Add a shell command, argument vector, environment field, device, network mode, or unknown plan field | Reject before process launch                                                | `vm-launch-field-unknown`; closed-vocabulary test          |
+| Put WHPX in a TCG plan, TCG in a WHPX plan, or request a fallback                                    | Reject rather than downgrade, cross-route, or overclaim                     | Separate schemas; accelerator/unknown-field tests          |
+| Replace any QEMU executable, DLL, firmware file, kernel, or initramfs before measurement             | Reject before process launch                                                | Runtime, binary, kernel, and initrd digest mismatch issues |
+| Replace measured files while the launch snapshot is being created                                    | Reject the snapshot                                                         | Runtime, kernel, and initrd snapshot mismatch issues       |
+| Replace caller-owned files after the first launch                                                    | Second launch still uses the same private snapshot                          | Private-snapshot substitution test                         |
+| Persistently self-modify the private runtime or guest artifacts during a launch                      | Reject on post-launch remeasurement                                         | Private-snapshot drift test                                |
+| Inject QEMU behavior through inherited environment variables or user configuration                   | Launch with a minimal environment and `-no-user-config`                     | Generated-argv test                                        |
+| Obtain implicit host devices or a communication channel                                              | Start with `-nodefaults`, `-nic none`, USB off, no display, and no monitor  | Generated-argv test                                        |
+| Forge the guest signal, use the wrong exit path, or change adapter diagnostics                       | Reject the receipt and retain no raw output                                 | Console, exit-code, and diagnostic-digest tests            |
+| Make clean launches observably disagree                                                              | Reject deterministic coverage                                               | `vm-launch-nondeterministic`                               |
+| Inject a fake process runner through the public API                                                  | Ignore it and execute only the bound process implementation                 | Public process-runner injection test                       |
+| Select ambient execution, weaken a sandbox control, change the launcher, or forge its protocol       | Reject the distinct sandbox schema, launcher digest, or incomplete evidence | Closed sandbox vocabulary and protocol-forgery tests       |
+| Pass inherited parent handles into sandboxed QEMU                                                    | Admit only NUL input and the two bounded output pipes                       | Native handle-list evidence and receipt assertion          |
+| Spawn another process or escape launcher lifetime/resource bounds                                    | Assign suspended QEMU before resume to a one-process, kill-on-close Job     | Native Job evidence and adversarial receipt tests          |
+| Add an AppContainer capability, path grant, network mode, command, or fallback                        | Reject the distinct closed plan vocabulary before launch                    | AppContainer closed-vocabulary test                        |
+| Forge the AppContainer SID, capability count, profile cleanup, or grant evidence                      | Reject the closed native protocol                                            | AppContainer protocol-forgery test                         |
+| Read a caller-readable file outside the measured snapshot                                             | Require exact access-denied evidence from a zero-capability AppContainer     | Protected-sentinel canary and receipt assertion            |
+| Connect to the host loopback listener from compromised QEMU                                           | Require bounded WSA deny/drop evidence and no accepted connection            | Loopback canary and receipt assertion                      |
+| Put an operational path or guest output in the receipt                                               | Withhold it; report only digest and byte count                              | Receipt disclosure assertions                              |
 
 ## Fixed launch policy
 
@@ -73,6 +109,27 @@ produce the plan-pinned diagnostic digest after removal of only the exact,
 randomized private-executor prefix that QEMU repeats at diagnostic line starts. Raw
 stdout and stderr are never included in the receipt.
 
+The sandboxed adapter additionally copies the package-pinned launcher into the
+private measured snapshot. The launcher protocol is closed and binary-safe: it
+returns base64 child streams plus derived control evidence, and HoloSystem
+rejects unknown fields, non-canonical base64, an unbounded enabled-privilege
+count, a missing control, or launcher stderr. Launcher and QEMU snapshots are
+remeasured before and after both launches.
+
+The AppContainer adapter uses the same measured launcher but a distinct plan,
+protocol, and control vocabulary. It never accepts caller-specified capabilities
+or ACL paths. Each native invocation creates a fresh AppContainer profile,
+applies the fixed grants, runs both canaries, creates QEMU with the same zero
+capability `SECURITY_CAPABILITIES`, checks the suspended child token, and deletes
+the profile during cleanup. HoloSystem rejects a nonzero capability count,
+unexpected bounded denial code, accepted loopback connection, incomplete cleanup, or
+any unknown protocol field.
+
+The TCG AppContainer plan also fixes `tcg,tb-size=64`; a caller cannot enlarge
+the JIT translation buffer or relax the 512 MiB process limit. Its receipt keeps
+`hardware-hypervisor-acceleration` missing even when every confinement canary
+passes.
+
 ## Residual risk and next layer
 
 The QEMU runtime closure includes firmware data files and DLLs, so substitution
@@ -80,12 +137,23 @@ changes its digest. Hashing does not establish provenance or measured boot.
 Windows QEMU also cannot disable host crash-dump capture through this contract;
 `host-crash-dump-custody` remains an explicit boundary.
 
-QEMU is not yet placed in an AppContainer, restricted token, job-object filesystem
-sandbox, or separate host VM. `virtual-device-minimization` therefore describes
-only the generated guest-facing virtual device surface; it must not be read as
-host-process or physical-device isolation.
-
-The next stronger layer must add a separately measured Windows host-process
-sandbox and firmware/measured-boot evidence. It must not reinterpret WHPX
-execution as proof of either property, and it must continue to report IOMMU,
-device-assignment, crash-dump custody, and side-channel boundaries separately.
+The ambient adapters do not place QEMU behind an OS process sandbox.
+`virtual-device-minimization` therefore describes only their generated
+guest-facing virtual device surface.
+
+The sandboxed adapter is narrower than AppContainer or a separate host VM. Its
+filtered token retains normal read access allowed to the caller and does not
+create an OS network capability boundary. The QEMU command still contains no
+guest network device, but a compromised host QEMU process could use host
+network APIs. `host-filesystem-confidentiality` and `host-network-isolation`
+therefore remain explicit missing layers even when the declared process
+isolation controls verify. The launcher binary is measured, but source-to-binary
+reproducibility and code signing remain part of `qemu-runtime-supply-chain` and
+host correctness trust.
+
+The TCG AppContainer tracer implements capability-scoped filesystem and network
+denial without hardware acceleration; the WHPX form remains blocked on the
+validated host. It does not turn the Windows kernel into a separate trust
+domain. The next layers are a WHPX broker or independent host boundary and
+firmware/measured-boot evidence. IOMMU, device-assignment, crash-dump custody,
+host correctness, and side-channel boundaries remain separate.

package/native/windows-sandbox/Canary.c

@@ -0,0 +1,107 @@
+#define WIN32_LEAN_AND_MEAN
+#include <winsock2.h>
+#include <windows.h>
+#include <stdio.h>
+#include <wchar.h>
+
+static int read_token_integer(HANDLE token, TOKEN_INFORMATION_CLASS information_class, int fallback)
+{
+    DWORD required = 0;
+    BYTE *buffer;
+    int value;
+    GetTokenInformation(token, information_class, NULL, 0, &required);
+    if (required == 0) return fallback;
+    buffer = (BYTE *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, required);
+    if (buffer == NULL) return fallback;
+    if (!GetTokenInformation(token, information_class, buffer, required, &required)) {
+        HeapFree(GetProcessHeap(), 0, buffer);
+        return fallback;
+    }
+    value = *(int *)buffer;
+    HeapFree(GetProcessHeap(), 0, buffer);
+    return value;
+}
+
+int wmain(int argc, wchar_t **argv)
+{
+    HANDLE file = INVALID_HANDLE_VALUE;
+    HANDLE token = NULL;
+    WSADATA socket_data;
+    SOCKET socket_handle = INVALID_SOCKET;
+    struct sockaddr_in address;
+    fd_set writable;
+    fd_set exceptional;
+    struct timeval wait_time;
+    u_long nonblocking = 1;
+    int port;
+    int filesystem_error = 0;
+    int network_error = 0;
+    int app_container = 0;
+    int capability_count = -1;
+
+    if (argc != 5 || wcscmp(argv[1], L"--protected-sentinel") != 0 ||
+        wcscmp(argv[3], L"--loopback-port") != 0) return 64;
+    port = _wtoi(argv[4]);
+    if (port < 1 || port > 65535) return 64;
+
+    file = CreateFileW(
+        argv[2], GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING,
+        FILE_ATTRIBUTE_NORMAL, NULL
+    );
+    if (file == INVALID_HANDLE_VALUE) filesystem_error = (int)GetLastError();
+    else CloseHandle(file);
+
+    if (WSAStartup(MAKEWORD(2, 2), &socket_data) != 0) {
+        network_error = WSAGetLastError();
+    } else {
+        socket_handle = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
+        if (socket_handle == INVALID_SOCKET) {
+            network_error = WSAGetLastError();
+        } else {
+            ioctlsocket(socket_handle, FIONBIO, &nonblocking);
+            ZeroMemory(&address, sizeof(address));
+            address.sin_family = AF_INET;
+            address.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
+            address.sin_port = htons((u_short)port);
+            if (connect(socket_handle, (struct sockaddr *)&address, sizeof(address)) == SOCKET_ERROR) {
+                network_error = WSAGetLastError();
+                if (network_error == WSAEWOULDBLOCK) {
+                    FD_ZERO(&writable);
+                    FD_ZERO(&exceptional);
+                    FD_SET(socket_handle, &writable);
+                    FD_SET(socket_handle, &exceptional);
+                    wait_time.tv_sec = 2;
+                    wait_time.tv_usec = 0;
+                    if (select(0, NULL, &writable, &exceptional, &wait_time) > 0) {
+                        int socket_error = 0;
+                        int error_length = sizeof(socket_error);
+                        if (getsockopt(
+                            socket_handle, SOL_SOCKET, SO_ERROR,
+                            (char *)&socket_error, &error_length
+                        ) == 0) network_error = socket_error;
+                        else network_error = WSAGetLastError();
+                    } else {
+                        network_error = WSAETIMEDOUT;
+                    }
+                }
+            }
+            closesocket(socket_handle);
+        }
+        WSACleanup();
+    }
+
+    if (OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &token)) {
+        app_container = read_token_integer(token, TokenIsAppContainer, 0);
+        capability_count = read_token_integer(token, TokenCapabilities, -1);
+        CloseHandle(token);
+    }
+
+    printf(
+        "appContainer=%d;capabilityCount=%d;filesystemError=%d;networkError=%d\n",
+        app_container != 0 ? 1 : 0,
+        capability_count,
+        filesystem_error,
+        network_error
+    );
+    return 0;
+}