The Lind Project claims lind-wasm runs recompiled POSIX applications as mutually isolated compartments inside one unprivileged process with programmable syscall mediation, potentially providing reusable workload containment without kernel changes or per-application virtual machines.

state: seedheat: lowuncertainty: mediumconvergesscott: mediumagent-sandboxing systems-security wasmLind Project

What is this?

The Lind Project describes its software as a single-process sandbox for safely executing programs; its lind-wasm-apps repository supplies applications cross-compiled from source to wasm32-wasi using a custom glibc sysroot. The supplied research snippets also document Lind's legacy-application sandboxing work, including Chris Matthews's dissertation and a NaCl/RePy implementation with a subset of POSIX and resource-access policies. The case presents lind-wasm as a Wasmtime-based system for isolated application compartments, but the web snippets do not establish that backend, programmable syscall mediation, the named application demonstrations, or the claimed absence of kernel changes and per-application VMs; they also do not identify current maintainers or a dated release.

Why it matters to Scott

Lind’s single-process sandbox and cross-compiled WASI applications converge with Scott’s Sandboxed Execution and SiloOS containment architecture, offering a concrete substrate to evaluate alongside the Bubblewrap isolation used by his Songbird Codex and validation workers. The potential build decision is whether recompiled POSIX workloads can support his required execution boundaries, but programmable mediation, compartment guarantees and application compatibility remain unestablished by the supplied snippets; the radar tracks related WASM sandboxes, not this Lind development.

ip:concept.sandboxed-executiondev:project.silo-osdev:technology.bubblewrapradar:concept.sandboxingradar:concept.wasmradar:wasmer-local-agent-sandboxesradar:browserpod-codex-wasm

queries asked of Scott's wikis

coding agent harness untrusted code execution sandbox
tool execution permissions syscall mediation capability security
WebAssembly WASI POSIX application compatibility
agent workload isolation containers microVMs single-process sandbox
sandbox resource limits filesystem network access policies

Measured heat

now 0 pts/hpeak 0 pts/hcomments 0/hpeers p14momentum: steady2 platformsage 694h

points/hour across evidence · reading as of 2026-10-12 02:59:37.977291+11:00 · deterministic, not a model opinion

How the heat travelled

09-12 19:29 (minted)	⭐ origin echo-reconstructed	Presents lind-wasm as the currently supported Wasmtime-based backend, with NGINX, PostgreSQL, and Python running as compartments, public tes Lind Project on blog (echo) · attributed from hn.story.49675470 · published time unknown	—
09-12 18:25	first on hacker news · published · lag ?	Lind-project: Run untrusted POSIX applications, safely, in one process ryuuseijin	—
09-12 18:25	amplified on hacker news 👑	hn.story.49675470 ryuuseijin	peak 1 · 0 comments · 106% of case engagement
09-12 19:20	our radar first saw it · lag ?	discovery anchor: hn.story.49675470	—

pace: p9 vs 1032 stories at the 336h mark (now 694h old) — behind addom-local-coding-harness (0.5x)

Evidence (2) — ⭐ canonical anchor

source	object	author	score	comments
🟧 hn	Lind-project: Run untrusted POSIX applications, safely, in one process Retrieved article excerpt Open article · Retrieved 2026-09-12T19:22:11.801010+00:00 # Run untrusted POSIX applications, safely, in one process Lind executes untrusted POSIX applications as mutually isolated compartments inside a single unprivileged host process — no kernel modifications, no elevated privileges — while keeping the isolation mechanism pluggable and the system-call policy layer uniform. WebAssembly / Wasmtime / Intel MPK / More backends → One uniform mediation layer [Explore lind-wasm ↗](https://lind-project.github.io/lind-wasm/) [View on GitHub](https://github.com/Lind-Project/lind-wasm) $ recompile · sandbox · run — most C, C++ & Rust programs, unchanged PLUGGABLE ISOLATION BACKEND · CONFINES COMPARTMENTS & HANDLERS WebAssembly / Wasmtime ✓ · Intel MPK & more (planned) Compartment 1 NGINX Compartment 2 PostgreSQL Compartment 3 Python Policy handler user-space, per workload system calls mediation System-call mediation layer uniform interception, routing & policy — same across backends Trusted POSIX runtime minimal, services the calls passed through to it Why Lind ## Isolation and policy, finally decoupled Sandboxes usually entangle two concerns: how an application is confined, and how its system calls are mediated. Lind separates them cleanly — so isolation technology can evolve without rewriting policy, and policy can be composed without touching the isolation substrate. 📦 ### Compartments Each application runs as its own isolated instance with its own memory, control flow, and POSIX behavior — all inside one unprivileged host process. 🔀 ### Mediation layer A single programmable layer routes every system call, delegating each to the trusted runtime or to user-space policy handlers. Uniform across every isolation backend. 🛡️ ### Policy handlers User-space handlers that interpose on system calls — filter, transform, or service them entirely in user space, composable per workload. ⚙️ ### Trusted POSIX runtime A minimal runtime that services the calls the policy layer chooses to pass through — keeping the trusted computing base small. 🔌 ### Pluggable isolation backends The isolation substrate is deliberately swappable. WebAssembly software fault isolation (via Wasmtime) is the only backend supported today; others are being added, including hardware-assisted options such as Intel Memory Protection Keys (MPK) — each offering different performance and trust trade-offs, under the same mediation layer. 🧩 ### POSIX compatibility preserved Most C, C++, and Rust programs can be recompiled and sandboxed without source-code changes. A full LAMP stack (NGINX, PostgreSQL, Python) already runs as compartments today — natively on Linux, or via dev containers on Linux, macOS, and Windows. Projects ## One framework, growing family of backends lind-wasm is the mature, fully realized backend today — with end-to-end tests, benchmarks, dev containers, and public documentation. [★ Flagship — fully realized ### lind-wasm The WebAssembly backend, built on a modified Wasmtime and glibc. Runs a full LAMP stack as isolated compartments, with parts already served by user-space policy handlers. Ships with dev containers, an end-to-end test suite, benchmarks, and docs. Documentation ↗ github.com/Lind-Project/lind-wasm NGINX✓ runs as compartment PostgreSQL✓ runs as compartment Python✓ runs as compartment policy-handler mediation✓ partial stack e2e tests · benchmarks✓](https://lind-project.github.io/lind-wasm/) [Examples ### lind-wasm-example-grates Example user-space policy handlers showing how they interpose on and service system calls. github.com/Lind-Project/lind-wasm-example-grates →](https://github.com/Lind-Project/lind-wasm-example-grates) [Applications ### lind-wasm-apps Real-world POSIX applications ported to run as Lind compartments — the compatibility test bed. github.com/Lind-Project/lind-wasm-apps →](https://github.com/Lind-Project/lind-wasm-apps) Ongoing work SGX enclave support MPK & kernel backends Performance Shared-object library Where it runs ## Runs where you already work lind-wasm runs today in a Docker development container on macOS, Windows, and Linux — and natively on Linux for the lowest-overhead path from clone to running compartments. 🍎 ### macOS Run the full build-and-test toolchain inside the Lind dev container — no host setup beyond Docker. Docker dev container 🪟 ### Windows The same containerized workflow, so builds and tests behave identically across every machine. Docker dev container 🐧 ### Linux Use the dev container for parity, or build and run Lind natively for the fastest, leanest setup. Native · or Docker Roadmap ## Where Lind is headed next ### 1Supported host environment Now lind-wasm (Lind with wasm backend) runs in a Docker container on Linux, macOS, and Windows, and natively on Linux. ~6 mo Add support for running in an SGX enclave. Improve quick start for the environment. ### 2Isolation backends Now The Wasm backend (via Wasmtime) is fully realized and runs application suites as complex as a full LAMP stack. We are factoring the backend-facing interface out of the Wasmtime-specific code so that additional backends can implement it. ~12 mo An MPK backend that runs the core process model — cages, fork/exec/exit, and multi-cage execution — through 3i, reaching feature parity with the Wasm backend, including grate calls. ### 3Performance Now– 12 mo Establish performance baselines and optimize both the standalone and grate-call paths. ### 4Running Lind as a shared object library Now– 6 mo A prototype packages Lind itself as a shared library that a host application can load; within this embedded Lind, each untrusted library runs in its own cage. The host calls the library through the familiar shared-library interface, while the library executes fully isolated, with grates mediating its system calls. We are testing and hardening this support for real use in scientific library isolation. ### Roadmap context Today, Lind's WebAssembly/Wasmtime backend runs complex POSIX workloads, including a full LAMP stack, language interpreters, and various compilers. Lind runs natively on Linux and via development containers on Linux, macOS, and Windows, and an embeddable shared-library mode exists as a working prototype. Most C, C++, and Rust applications need only be recompiled to run under Lind, with no source-code changes. Over the next 12 months, the roadmap focuses on demonstrating in practice what Lind's architecture provides by design: isolation that is independent of any single backend. Our priorities are to broaden the environments in which Lind runs, validate 3i across additional isolation mechanisms — including hardware-assisted options such as MPK — improve performance on both the standalone and grate-call paths, and harden the shared-library mode for production use. Community ## Built in the open, together Lind is developed openly by a community of researchers and contributors. Join the conversation, come to a meeting, or open your first pull request. 📅 ### Monthly community meeting We meet once a month to discuss roadmap progress, design questions, and contributions. Everyone is welcome — add it to your calendar. [Add to Google Calendar](https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=MzdmMTJ0MGNhZ3QzbThmdDdrZW1kNDBucmdfMjAyNjA3MTBUMTQwMDAwWiB5dzcwMTNAbnl1LmVkdQ&tmsrc=yw7013%40nyu.edu&scp=ALL) 💬 ### Chat on Slack Questions, ideas, or just curious? Find us in the `#lind` channel of the Secure Systems Lab Slack. [Join us on Slack](https://secure-systems-lab.slack.com/archives/CBKAGSC9Z) 🐙 ### Contribute on GitHub Issues, discussions, and pull requests all happen in the open. Contributing guides and good first issues live in the repos. [Explore the repo](https://github.com/Lind-Project/lind-wasm) ## Start with the realized backend lind-wasm is ready to explore today — documentation, dev containers, and a test suite to get you from clone to running compartments. [Read the docs ↗](https://lind-project.github.io/lind-wasm/) [Clone the repo](https://github.com/Lind-Project/lind-wasm)	ryuuseijin	1	0
🟧 echo.blog ⭐	Presents lind-wasm as the currently supported Wasmtime-based backend, with NGINX, PostgreSQL, and Python running as compartments, public tes	Lind Project	—	—

source

object

author

score

comments

🟧 hn

Lind-project: Run untrusted POSIX applications, safely, in one process

Retrieved article excerpt

Open article · Retrieved 2026-09-12T19:22:11.801010+00:00

# Run untrusted POSIX applications, safely, in one process

Lind executes untrusted POSIX applications as mutually isolated **compartments** inside
a single unprivileged host process — no kernel modifications, no elevated privileges — while keeping
the isolation mechanism pluggable and the system-call policy layer uniform.

WebAssembly / Wasmtime
/
Intel MPK
/
More backends
→
One uniform mediation layer

[Explore lind-wasm ↗](https://lind-project.github.io/lind-wasm/)
[View on GitHub](https://github.com/Lind-Project/lind-wasm)

$ recompile · sandbox · run — most C, C++ & Rust programs, unchanged

PLUGGABLE ISOLATION BACKEND · CONFINES COMPARTMENTS & HANDLERS
WebAssembly / Wasmtime ✓ · Intel MPK & more (planned)

Compartment 1
NGINX

Compartment 2
PostgreSQL

Compartment 3
Python

Policy handler
user-space, per workload

system calls

mediation

System-call mediation layer
uniform interception, routing & policy — same across backends

Trusted POSIX runtime
minimal, services the calls passed through to it

Why Lind

## Isolation and policy, finally decoupled

Sandboxes usually entangle two concerns: *how* an application is confined, and *how* its
system calls are mediated. Lind separates them cleanly — so isolation technology can evolve
without rewriting policy, and policy can be composed without touching the isolation substrate.

📦

### Compartments

Each application runs as its own isolated instance with its own memory, control flow, and POSIX behavior — all inside one unprivileged host process.

🔀

### Mediation layer

A single programmable layer routes every system call, delegating each to the trusted runtime or to user-space policy handlers. Uniform across every isolation backend.

🛡️

### Policy handlers

User-space handlers that interpose on system calls — filter, transform, or service them entirely in user space, composable per workload.

⚙️

### Trusted POSIX runtime

A minimal runtime that services the calls the policy layer chooses to pass through — keeping the trusted computing base small.

🔌

### Pluggable isolation backends

The isolation substrate is deliberately swappable. WebAssembly software fault isolation (via Wasmtime) is the only backend supported today; others are being added, including hardware-assisted options such as Intel Memory Protection Keys (MPK) — each offering different performance and trust trade-offs, under the same mediation layer.

🧩

### POSIX compatibility preserved

Most C, C++, and Rust programs can be recompiled and sandboxed without source-code changes. A full LAMP stack (NGINX, PostgreSQL, Python) already runs as compartments today — natively on Linux, or via dev containers on Linux, macOS, and Windows.

Projects

## One framework, growing family of backends

lind-wasm is the mature, fully realized backend today — with end-to-end tests, benchmarks,
dev containers, and public documentation.

[★ Flagship — fully realized

### lind-wasm

The WebAssembly backend, built on a modified Wasmtime and glibc. Runs a full LAMP
stack as isolated compartments, with parts already served by user-space policy handlers.
Ships with dev containers, an end-to-end test suite, benchmarks, and docs.

Documentation ↗
github.com/Lind-Project/lind-wasm

NGINX✓ runs as compartment

PostgreSQL✓ runs as compartment

Python✓ runs as compartment

policy-handler mediation✓ partial stack

e2e tests · benchmarks✓](https://lind-project.github.io/lind-wasm/)
[Examples

### lind-wasm-example-grates

Example user-space policy handlers showing how they interpose on and service system calls.

github.com/Lind-Project/lind-wasm-example-grates →](https://github.com/Lind-Project/lind-wasm-example-grates)
[Applications

### lind-wasm-apps

Real-world POSIX applications ported to run as Lind compartments — the compatibility test bed.

github.com/Lind-Project/lind-wasm-apps →](https://github.com/Lind-Project/lind-wasm-apps)

Ongoing work

SGX enclave support
MPK & kernel backends
Performance
Shared-object library

Where it runs

## Runs where you already work

lind-wasm runs today in a Docker development container on macOS, Windows, and Linux — and
natively on Linux for the lowest-overhead path from clone to running compartments.

🍎

### macOS

Run the full build-and-test toolchain inside the Lind dev container — no host setup beyond Docker.

Docker dev container

🪟

### Windows

The same containerized workflow, so builds and tests behave identically across every machine.

Docker dev container

🐧

### Linux

Use the dev container for parity, or build and run Lind natively for the fastest, leanest setup.

Native · or Docker

Roadmap

## Where Lind is headed next

### 1Supported host environment

Now

lind-wasm (Lind with wasm backend) runs in a Docker container on Linux, macOS, and Windows, and natively on Linux.

~6 mo

Add support for running in an SGX enclave. Improve quick start for the environment.

### 2Isolation backends

Now

The Wasm backend (via Wasmtime) is fully realized and runs application suites as complex as a full LAMP stack. We are factoring the backend-facing interface out of the Wasmtime-specific code so that additional backends can implement it.

~12 mo

An MPK backend that runs the core process model — cages, fork/exec/exit, and multi-cage execution — through 3i, reaching feature parity with the Wasm backend, including grate calls.

### 3Performance

Now– 12 mo

Establish performance baselines and optimize both the standalone and grate-call paths.

### 4Running Lind as a shared object library

Now– 6 mo

A prototype packages Lind itself as a shared library that a host application can load; within this embedded Lind, each untrusted library runs in its own cage. The host calls the library through the familiar shared-library interface, while the library executes fully isolated, with grates mediating its system calls. We are testing and hardening this support for real use in scientific library isolation.

### Roadmap context

Today, Lind's WebAssembly/Wasmtime backend runs complex POSIX workloads, including a full
LAMP stack, language interpreters, and various compilers. Lind runs natively on Linux and
via development containers on Linux, macOS, and Windows, and an embeddable shared-library
mode exists as a working prototype. Most C, C++, and Rust applications need only be
recompiled to run under Lind, with no source-code changes.

Over the next 12 months, the roadmap focuses on demonstrating in practice what Lind's
architecture provides by design: isolation that is independent of any single backend. Our
priorities are to broaden the environments in which Lind runs, validate 3i across
additional isolation mechanisms — including hardware-assisted options such as MPK —
improve performance on both the standalone and grate-call paths, and harden the
shared-library mode for production use.

Community

## Built in the open, together

Lind is developed openly by a community of researchers and contributors.
Join the conversation, come to a meeting, or open your first pull request.

📅

### Monthly community meeting

We meet once a month to discuss roadmap progress, design questions, and contributions. Everyone is welcome — add it to your calendar.

[Add to Google Calendar](https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=MzdmMTJ0MGNhZ3QzbThmdDdrZW1kNDBucmdfMjAyNjA3MTBUMTQwMDAwWiB5dzcwMTNAbnl1LmVkdQ&tmsrc=yw7013%40nyu.edu&scp=ALL)

💬

### Chat on Slack

Questions, ideas, or just curious? Find us in the `#lind` channel of the Secure Systems Lab Slack.

[Join us on Slack](https://secure-systems-lab.slack.com/archives/CBKAGSC9Z)

🐙

### Contribute on GitHub

Issues, discussions, and pull requests all happen in the open. Contributing guides and good first issues live in the repos.

[Explore the repo](https://github.com/Lind-Project/lind-wasm)

## Start with the realized backend

lind-wasm is ready to explore today — documentation, dev containers, and a test suite to get you from clone to running compartments.

[Read the docs ↗](https://lind-project.github.io/lind-wasm/)
[Clone the repo](https://github.com/Lind-Project/lind-wasm)

ryuuseijin

🟧 echo.blog ⭐

Presents lind-wasm as the currently supported Wasmtime-based backend, with NGINX, PostgreSQL, and Python running as compartments, public tes

Lind Project

—

Interpretation history

2026-09-12T19:33:43Z
grounded: converges/medium — Lind’s single-process sandbox and cross-compiled WASI applications converge with Scott’s Sandboxed Execution and SiloOS containment architecture, offering a con
2026-09-12T19:29:35Z
case created — A usable isolation implementation offers transferable containment lessons, but the evidence establishes neither lower overhead nor agent-specific validation.

Decision trace

10-04 08:34review_dormantscheduled targets exhausted or 28 quiet days
10-04 08:34drop_targetsquiet through full ladder or over cap 8
09-13 05:33groundLind’s single-process sandbox and cross-compiled WASI applications converge with Scott’s Sandboxed Execution and SiloOS containment architecture, offering a concrete substrate to evaluate alongside th
09-13 05:29createA usable isolation implementation offers transferable containment lessons, but the evidence establishes neither lower overhead nor agent-specific validation.