Support for landlock ABI v5?

[tiran]

Would it be possible to support systems with ABI v5? It would enable us to run sandlock on top of RHEL 9 Kernel. I'm mostly interested in FS and network sandboxing. ABI v6 added LANDLOCK_SCOPE_SIGNAL and LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET. The Kernel docs have an example how to rescope a ruleset.

$ sandlock --version
sandlock 0.6.0
$ sandlock check
Kernel feature support:
  Landlock:       ABI v5
  Minimum required: ABI v6
  Status:         UNSUPPORTED (upgrade kernel)
  Filesystem:     supported (ABI v1+)
  File truncate:  supported (ABI v3+)
  TCP ports:      supported (ABI v4+)
  Device ioctl:   supported (ABI v5+)
  IPC scoping:    not supported
  Signal scoping: not supported
  Platform: x86_64

$ uname -r
5.14.0-570.79.1.el9_6.x86_64

[congwang-mk]

Requiring ABI v6 is deliberate. v6 is what lets sandlock close two escape paths that v5 leaves open, and we treat that as part of the security guarantee, not an optional extra.

We unconditionally enable two v6-only scopes:

• LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET: without it, a sandboxed process can connect() to any abstract Unix socket in the host namespace (D-Bus session bus, ssh-agent/gpg-agent, X11/Wayland on abstract sockets, snapd, etc.). The FS allowlist can't block these because abstract sockets don't live on the filesystem.
• LANDLOCK_SCOPE_SIGNAL: without it, the sandboxed PID can kill(2) any process owned by the invoking UID (supervisor, sibling sandboxes, user-session daemons). A DoS and integrity leak across the boundary.

Your FS + TCP use case is genuinely well-served by v5 (path-beneath, REFER, truncate, TCP bind/connect, device ioctl all work), but without the v6 scopes the sandbox boundary leaks laterally through kernel IPC, and we don't want to ship a mode that silently degrades that guarantee depending on the host kernel.

Curious how you'd weigh this for your setup: is the v5-level FS+TCP jail still useful to you knowing the IPC/signal boundary isn't enforced, or does that change the calculus?

[cccs-jaw]

Hello, I have hit the same issue unfortunately.

Using ABI v6 as a secure default makes sense. At the same time, the Policy object already allows for specific usability / risk trade-offs to this secure by default model. Could we enable the ability to configure a Policy object away from this secure default that explicitly/implicitly drops the requirement on v6 Landlock ABI? I.e allowlist socket I/O and sending signals.

Lots of server infrastructure run LTS OS Versions, like Ubuntu 24.04. This limitation prevents containerized apps (ie a Kubernetes nodes) from using Sandlock, which is where I see a common use-case for Sandlock: where a node is already isolated from the system via containerization, but the code within the node wants to apply further hardening by extension.