What are the capability limits in Landlock mode?

[SuperManito]

Your documentation seems a bit disorganized; I couldn't find a detailed description of enabling the --landlock-apply option.

I'm developing sandbox functionality for a container environment. I tried using the native implementation of bubblewrap, but it's known to require privileged mode (--privileged) to function properly until I discovered this project.

After testing, the --landlock-apply mode works in a container environment (Debian 13). However, I haven't found a detailed description of it after reading the documentation for a long time. Even your test module isn't compatible. Furthermore, using this command option ignores other command options.

Could you tell me the capabilities of landlock mode? Does it also support network filtering, etc.? I urgently need a sandbox project based on landlock out of the box because other projects don't provide binary installations.

[jy-tan]

Thanks for trying Fence!

--landlock-apply isn't a user-facing mode, but an internal helper that the parent fence process re-execs into from inside its bubblewrap sandbox to apply Landlock rules to your command. Because it's dispatched before normal CLI parsing, other flags look like they're being ignored, and that's why it's not in --help.

Worth sharing that when you run fence --landlock-apply -- <cmd> directly (outside a parent Fence process), you're not getting the rest of Fence's sandbox (no bwrap, no seccomp, no proxy, no namespaces) - it's mostly just exec'ing your command. So if it appears to be "working", that's largely the absence of restrictions, not Landlock in action.

For your container setup, just run fence -- <your command> (or fence -t code -- <cmd>) normally. Inside an unprivileged container, Fence detects that CAP_NET_ADMIN is missing, automatically skips the network namespace, and still gives you:

• bubblewrap mount isolation (read-only root, allowlisted writes, etc.)
• Landlock filesystem rules (kernel 5.13+)
• seccomp filtering and PID isolation
• proxy-based domain filtering for any program that respects HTTP_PROXY / HTTPS_PROXY

What you lose without CAP_NET_ADMIN is namespace-level network blocking, so a process that opens raw sockets and ignores proxy env vars can reach the network.

On your Landlock-network question: Landlock ABI v4+ does have TCP bind/connect rules, but Fence currently uses Landlock for filesystem only. Network policy is enforced via the network namespace + local proxies.

Run fence --linux-features inside your container to confirm bwrap and socat are both present, that's the minimum requirement. If either is missing let me know what your environment looks like.

And fair point on the docs - --landlock-apply shouldn't be discoverable as a user flag or rename it to signal that it's internal, and will consider adding guidance for running Fence inside a container.

[SuperManito]

Thanks for trying Fence!

--landlock-apply isn't a user-facing mode, but an internal helper that the parent fence process re-execs into from inside its bubblewrap sandbox to apply Landlock rules to your command. Because it's dispatched before normal CLI parsing, other flags look like they're being ignored, and that's why it's not in .--help

Worth sharing that when you run directly (outside a parent Fence process), you're not getting the rest of Fence's sandbox (no bwrap, no seccomp, no proxy, no namespaces) - it's mostly just exec'ing your command. So if it appears to be "working", that's largely the absence of restrictions, not Landlock in action.fence --landlock-apply -- <cmd>

For your container setup, just run (or ) normally. Inside an unprivileged container, Fence detects that is missing, automatically skips the network namespace, and still gives you:fence -- <your command>``fence -t code -- <cmd>``CAP_NET_ADMIN

• bubblewrap mount isolation (read-only root, allowlisted writes, etc.)
• Landlock filesystem rules (kernel 5.13+)
• seccomp filtering and PID isolation
• proxy-based domain filtering for any program that respects HTTP_PROXY / HTTPS_PROXY

What you lose without is namespace-level network blocking, so a process that opens raw sockets and ignores proxy env vars can reach the network.CAP_NET_ADMIN

On your Landlock-network question: Landlock ABI v4+ does have TCP bind/connect rules, but Fence currently uses Landlock for filesystem only. Network policy is enforced via the network namespace + local proxies.

Run inside your container to confirm bwrap and socat are both present, that's the minimum requirement. If either is missing let me know what your environment looks like.fence --linux-features

And fair point on the docs - shouldn't be discoverable as a user flag or rename it to signal that it's internal, and will consider adding guidance for running Fence inside a container.--landlock-apply

Thank you for your reply. As it turns out, enabling --landlock-apply did not enable the sandbox function; instead, the command was executed directly. I roughly understand how the fence works. That brings us back to the original question: how do I use a sandbox in a non-privileged container?

$ fence -- echo "hello world"
Error: failed to wrap command: bubblewrap (bwrap) is required on Linux but not found: exec: "bwrap": executable file not found in $PATH

$ apt-get install -y bubblewrap
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  bubblewrap
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 52.0 kB of archives.
After this operation, 140 kB of additional disk space will be used.
Get:1 http://mirrors.aliyun.com/debian trixie/main amd64 bubblewrap amd64 0.11.0-2 [52.0 kB]
Fetched 52.0 kB in 0s (281 kB/s)      
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 79, <STDIN> line 1.)
debconf: falling back to frontend: Readline
Selecting previously unselected package bubblewrap.
(Reading database ... 41441 files and directories currently installed.)
Preparing to unpack .../bubblewrap_0.11.0-2_amd64.deb ...
Unpacking bubblewrap (0.11.0-2) ...
Setting up bubblewrap (0.11.0-2) ...
Processing triggers for procps (2:4.0.4-9) ...
procps: Applying updated sysctl configuration
sysctl: permission denied on key "kernel.unprivileged_userns_clone"

$ fence -- echo "hello world"
bwrap: Creating new namespace failed: Operation not permitted

$ fence --landlock-apply -- echo "hello world"
hello world

$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.4
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

$ uname -a 
Linux arcadia 6.12.73+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.73-1 (2026-02-17) x86_64 GNU/Linux

bwrap: Creating new namespace failed: Operation not permitted
This error message matches my previous test results.

As I mentioned earlier, starting a container with --privileged carries greater risks and is not worth the effort. So I turned my attention to Landlock technology.

I've studied the sandbox implementations of mainstream AI CLI tools. They also use Bubblewrap on Linux.

• https://github.com/openai/codex/tree/main/codex-rs/linux-sandbox
• https://github.com/anthropic-experimental/sandbox-runtime

Can you provide the capabilities of https://github.com/Zouuup/landrun ?