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.

That comes with security implications. In simple words, a breach in any of the parts of the massive code base could potentially affect the entire system.

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. So Collabora reworked the multi-tenant feature, so 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, now 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. 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. 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.