Collabora: Landlock adds a third, tougher sandbox tier

Hub 26 Summer launches live!

Join us for the livestream and be among the first to discover
what’s new in Nextcloud.

September 16 @ 3 PM CEST / 9 AM EDT

Watch live on YouTube or PeerTube

Set a reminder

To protect a whole server from a breach in any component, Collabora Online isolates every document in its own kit process. Until now there were two ways to do that: chroot with capabilities, or user namespaces. Both have their limitations in terms of security, performance, complexity and compatibility. Collabora Online 26.04.3-3 adds the new Landlock kernel feature as a third path, beating quite some other solutions to it.

Chroot and namespace both have their limits

Chroot mode locks the Kit process into a mini filesystem. That takes two Linux capabilities, kernel permissions for specific system functions, independent of root: CAP_SYS_CHROOT for locking in, CAP_SYS_ADMIN for mounting. Root sets both on coolforkit and coolmount during package install. Reliable, but a hard requirement on your permission structure.

Namespace mode needs no capability setup. Instead, the kernel has to allow unprivileged users to create their own user namespaces. But that is disabled by policy in a lot of container and hosting environments.

If namespaces are blocked and capabilities aren’t set, your setup used to fall back to a slow fallback path. Or you had to patch things up with a custom seccomp profile. With RichDocumentsCode, the bundled app variant typical for personal deployments, all that was left was a minimal base sandbox.

What Landlock changes

Landlock is a Linux Security Module (LSM) in the kernel, available since 5.13. A process restricts itself with it, no privileges are required. The Collabora Online WebSocket Daemon (coolwsd) tells each Kit child process exactly what filesystem access it gets, no matter what capabilities or namespace policy allows.

One limitation remains: Landlock can’t mount. Collabora reworked the multi-tenant feature: org-wide settings like templates and custom dictionaries still start fast, even without bind mounts.

Server operation barely changes. coolwsd still tries namespaces first, then capabilities, then Landlock as a third tier. Existing deployments won’t notice the switch. Landlock is available for both connection types, though the fallback order differs: server mode keeps namespaces first, RichDocumentsCode now tries Landlock first.

170x faster than the fallback

Landlock isolates a Kit process in a median 602 microseconds. Bind mount takes 842 microseconds. The old «link or copy» fallback, the workaround without mounting, takes 104,471 microseconds. That makes Landlock about 170 times faster. If you’re stuck on that fallback, you’ll notice this update not just in security, but every time you open a document.

Check the prerequisite

Run this command: cat /sys/kernel/security/lsm

If landlock shows up in the output, you’re set. It’s default since Ubuntu 22.04 (kernel 5.15), Debian 12 «Bookworm» (kernel 6.1), and RHEL 9 (and derivatives like Rocky/AlmaLinux) from 9.6 onwards, and every newer version. 

Get your update right now

Update to 26.04.3-3. Landlock gives every deployment a stronger, kernel-enforced sandbox: no downside for typical setups, no config changes required.

It matters most if you’re stuck on the fallback because namespaces are blocked by policy, or you’re running RichDocumentsCode without capabilities. But even if your setup runs fine today, update anyway and get better isolation for free. One catch for Nextcloud on Docker: check the host’s kernel, not the container’s, since that’s what Landlock reads.

Update now, run the LSM check above, and confirm landlock shows up.