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

Lind moves toward a more portable, backend-independent framework — broadening where it runs, validating the mediation layer across new software- and hardware-based isolation mechanisms, improving performance, and hardening the shared-library mode.

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