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 ↗ View on GitHub
$ 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
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 → 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 →
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
💬

Chat on Slack

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

Join us on Slack
🐙

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

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 ↗ Clone the repo