I'd like to explore a developer-oriented default profile for Island that makes it practical to leave sandboxing enabled during normal software development.
Island already has what I think is the most useful abstraction for this: security policies associated with the directory/activity being worked on rather than individual applications.
That potentially allows the same sandbox to transparently cover package managers, build tools, arbitrary CLIs, IDE tooling, and AI coding agents without requiring each tool to implement its own sandbox.
I'd be interested in contributing implementation work if this direction fits the project's goals.
Motivation
Modern development routinely executes code that the developer did not directly write or audit:
- npm/pnpm lifecycle scripts and dependencies
- Python package/build hooks
- Cargo
build.rs
- compiler/build-system plugins
- linters and formatters
- downloaded CLI tools
- IDE tooling/extensions
- AI coding agents
Normally, all of this runs with the filesystem permissions of the developer's user account.
That means arbitrary code running during something as ordinary as a package installation generally does not need privilege escalation to read or modify unrelated files owned by the developer.
The security boundary I would usually want while working on a project is much narrower:
Code executed while working on project X should be able to work normally inside project X, but should not implicitly have access to unrelated data elsewhere in my home directory.
Why Island seems like a good fit
Island's context-aware shell integration already gets very close to this UX.
Conceptually:
cd ~/src/my-project
↓
project security context becomes active
↓
npm / pnpm / cargo / python / make
Claude / Codex / arbitrary CLI
↓
all inherit the same sandbox
This is different from requiring:
sandbox npm install
sandbox make
sandbox claude
or requiring npm, an AI agent, an IDE, etc. to each implement their own sandbox.
The directory/activity establishes the security context.
An already-sandboxed descendant also cannot escape simply by changing its own working directory. If a sandboxed tool executes cd /, it remains inside its existing Landlock restrictions; leaving the project directory only affects profile selection for new commands launched by the original interactive shell.
Proposed developer default
I think it would be useful if creating a development profile could produce a reasonably secure working configuration without requiring the user to design a Landlock policy manually.
The exact CLI/API is obviously open for discussion, but conceptually it might be something like:
cd ~/src/my-project
island create --developer my-project
with defaults approximately equivalent to:
~/src/my-project/** read/write
required system paths read/execute
required toolchain paths read/execute
Island workspace/XDG read/write
temporary workspace read/write
unrelated $HOME data inaccessible by default
other projects inaccessible by default
Common development directories such as package/compiler caches could then be allowed explicitly or inferred where appropriate.
The goal would be to make this workflow practical:
cd ~/src/my-project
pnpm install
npm test
cargo build
make
python ...
claude
codex
./some-untrusted-cli
without changing how any of those tools are invoked.
Relationship to existing TODOs
This seems complementary to several things already on Island's roadmap rather than requiring a separate sandboxing architecture.
In particular, the existing Default profiles TODO says:
Auto-create working profiles by parsing PATH and adding common directory access when no config exists.
That seems like a natural foundation for a developer-oriented preset.
The existing TODOs for better diagnostics / error messages and logging denied requests would also make restrictive developer profiles easier to use, since developers need to understand what access a build or tool requires when something is blocked.
Island also documents additional hardening areas such as environment filtering, TTY isolation and outside IPC interactions. I don't think those need to block or be part of this proposal; they can remain independent improvements to Island's overall security model.
Threat model / initial scope
I would keep the initial guarantee intentionally small and understandable:
Commands automatically launched in a development project context can work normally within that project and explicitly required development-tool directories, while unrelated user data is inaccessible by default.
The primary goal is reducing the blast radius of arbitrary code already executing as the developer's normal user.
For example, a compromised dependency running during installation should ideally be unable to:
read unrelated files elsewhere in $HOME
modify another repository
delete personal documents
modify unrelated user configuration
even though the dependency was legitimately launched by the developer.
This is complementary to package-manager protections such as lockfiles, release-age/cooldown policies and lifecycle-script controls. Those mechanisms try to prevent malicious code from executing in the first place; Island would limit what it can do if execution nevertheless occurs.
Non-goals for the initial proposal
I don't think the first implementation needs to solve every sandboxing problem.
For example, this proposal does not need to initially address:
- fine-grained protection of sensitive files inside an otherwise writable workspace
- network/domain filtering
- environment-secret filtering
- D-Bus/Wayland isolation
- interactive permission prompts
- full container/VM-style isolation
Those are useful additional layers, and several already overlap with Island's documented roadmap or limitations.
The value of the developer profile would exist independently: substantially reducing filesystem access outside the project with very little workflow friction.
Presets vs special cases
I'd prefer this to remain a generic Island concept rather than hard-coding behavior for npm, Cargo, Python, AI agents, etc.
For example, a developer preset could compile down to an ordinary Island profile with sensible defaults.
Package-manager/toolchain presets could potentially be added later:
developer
developer + node
developer + rust
developer + python
but the underlying policy should remain transparent and editable.
This would keep Island generic while making the common development use case much easier to adopt.
Why I think the UX matters
The kernel primitive already exists and Island already provides transparent context-based enforcement.
The remaining problem is largely usability.
If enabling a reasonably secure development environment requires developers to manually understand every filesystem path used by their compiler, package manager and tools before they can start working, most developers will simply run without a sandbox.
If the secure path is instead approximately:
cd project
island create <profile>
followed by normal commands, it becomes realistic to keep the sandbox active all day.
That could make Island useful not just for intentionally running a particular untrusted application, but as a general security boundary for everyday software development.
Contribution
I'm happy to contribute implementation work if this direction makes sense for Island.
Before starting on a particular design, I'd mainly like maintainer feedback on:
- Does a developer-oriented secure default/preset fit Island's intended scope?
- Should this extend the existing Default profiles work, or be modeled separately as an explicit preset?
- What should the minimum default filesystem access be for such a profile?
- Would you prefer an initial implementation to focus only on profile generation, leaving tooling/package-manager-specific conveniences for later?
I'm also happy to start with a smaller piece if there is a particular part of the existing roadmap that would be a better prerequisite.
I'd like to explore a developer-oriented default profile for Island that makes it practical to leave sandboxing enabled during normal software development.
Island already has what I think is the most useful abstraction for this: security policies associated with the directory/activity being worked on rather than individual applications.
That potentially allows the same sandbox to transparently cover package managers, build tools, arbitrary CLIs, IDE tooling, and AI coding agents without requiring each tool to implement its own sandbox.
I'd be interested in contributing implementation work if this direction fits the project's goals.
Motivation
Modern development routinely executes code that the developer did not directly write or audit:
build.rsNormally, all of this runs with the filesystem permissions of the developer's user account.
That means arbitrary code running during something as ordinary as a package installation generally does not need privilege escalation to read or modify unrelated files owned by the developer.
The security boundary I would usually want while working on a project is much narrower:
Why Island seems like a good fit
Island's context-aware shell integration already gets very close to this UX.
Conceptually:
This is different from requiring:
or requiring npm, an AI agent, an IDE, etc. to each implement their own sandbox.
The directory/activity establishes the security context.
An already-sandboxed descendant also cannot escape simply by changing its own working directory. If a sandboxed tool executes
cd /, it remains inside its existing Landlock restrictions; leaving the project directory only affects profile selection for new commands launched by the original interactive shell.Proposed developer default
I think it would be useful if creating a development profile could produce a reasonably secure working configuration without requiring the user to design a Landlock policy manually.
The exact CLI/API is obviously open for discussion, but conceptually it might be something like:
with defaults approximately equivalent to:
Common development directories such as package/compiler caches could then be allowed explicitly or inferred where appropriate.
The goal would be to make this workflow practical:
without changing how any of those tools are invoked.
Relationship to existing TODOs
This seems complementary to several things already on Island's roadmap rather than requiring a separate sandboxing architecture.
In particular, the existing Default profiles TODO says:
That seems like a natural foundation for a developer-oriented preset.
The existing TODOs for better diagnostics / error messages and logging denied requests would also make restrictive developer profiles easier to use, since developers need to understand what access a build or tool requires when something is blocked.
Island also documents additional hardening areas such as environment filtering, TTY isolation and outside IPC interactions. I don't think those need to block or be part of this proposal; they can remain independent improvements to Island's overall security model.
Threat model / initial scope
I would keep the initial guarantee intentionally small and understandable:
The primary goal is reducing the blast radius of arbitrary code already executing as the developer's normal user.
For example, a compromised dependency running during installation should ideally be unable to:
even though the dependency was legitimately launched by the developer.
This is complementary to package-manager protections such as lockfiles, release-age/cooldown policies and lifecycle-script controls. Those mechanisms try to prevent malicious code from executing in the first place; Island would limit what it can do if execution nevertheless occurs.
Non-goals for the initial proposal
I don't think the first implementation needs to solve every sandboxing problem.
For example, this proposal does not need to initially address:
Those are useful additional layers, and several already overlap with Island's documented roadmap or limitations.
The value of the developer profile would exist independently: substantially reducing filesystem access outside the project with very little workflow friction.
Presets vs special cases
I'd prefer this to remain a generic Island concept rather than hard-coding behavior for npm, Cargo, Python, AI agents, etc.
For example, a developer preset could compile down to an ordinary Island profile with sensible defaults.
Package-manager/toolchain presets could potentially be added later:
but the underlying policy should remain transparent and editable.
This would keep Island generic while making the common development use case much easier to adopt.
Why I think the UX matters
The kernel primitive already exists and Island already provides transparent context-based enforcement.
The remaining problem is largely usability.
If enabling a reasonably secure development environment requires developers to manually understand every filesystem path used by their compiler, package manager and tools before they can start working, most developers will simply run without a sandbox.
If the secure path is instead approximately:
followed by normal commands, it becomes realistic to keep the sandbox active all day.
That could make Island useful not just for intentionally running a particular untrusted application, but as a general security boundary for everyday software development.
Contribution
I'm happy to contribute implementation work if this direction makes sense for Island.
Before starting on a particular design, I'd mainly like maintainer feedback on:
I'm also happy to start with a smaller piece if there is a particular part of the existing roadmap that would be a better prerequisite.