support guest Landlock syscalls for in-sandbox application sandboxing

[lukehinds]

Description

gVisor currently does not expose the Linux Landlock ABI. Tools such as nono and openai codex use Landlock as an unprivileged, inherited, kernel-enforced sandbox for filesystem, networking, and process/IPC scoping. When run inside a gVisor container, these tools cannot apply their expected sandbox policy.

As one of the maintainers of nono, I have had a good few users asking about gVisor support and it makes sense why - they compose really well together with the strong isolation model of gvisor and nono's capability based policy model.

Is this feature related to a specific bug?

Its a feature request.

Do you have a specific solution in mind?

current gVisor syscall tables do not register:

• landlock_create_ruleset
• landlock_add_rule
• landlock_restrict_self

So Applications probing Landlock observe it as unavailable.

An incremental path (if prefered) could be the following as we walk up the ABI versions, or even better include support for all - but we need to consider managing older kernels

1. Landlock V3 filesystem enforcement.
2. Landlock V4 TCP port enforcement.
3. Landlock V5/V6 device ioctl and scoping.
4. Landlock ABI 7 (audit)

cc @EtiennePerot and @l0kod

[EtiennePerot]

Sounds good. btw, the Landlock subsystem should be a perfect litmus test for the newly-added skill at https://github.com/google/gvisor/blob/master/.claude/skills/add-syscall/SKILL.md since it's a meaningfully-complex but well-isolated set of syscalls that should be testable against Linux as reference implementation.

[lukehinds]

@EtiennePerot sorry for radio silence, is this something you want to implement, or we are happy to do the work on our side and have you put eyes on the review?

[panga]

Waiting for this 👍

[caiodallaqua]

Same here.

[lukehinds]

Just looping back on this @EtiennePerot we are happy to take the work on and will get started, it sounds like your very open to accepting this as a feature and can help review.