Collabora Online process isolation: chroot and seccomp

Why Collabora Online process isolation matters for shared document editing

Security teams should treat process isolation as a primary control for Collabora Online, because the server opens documents that come from many users and from integrated hosts, and some of those documents will be untrusted. A malformed or booby-trapped file that exploits a parser flaw in the document engine could otherwise reach more than the one file being edited. Collabora Online handles each document in its own Kit process, and that process is meant to be confined by a chroot jail, dropped Linux capabilities and seccomp filtering. The goal of these layers is containment: if a parser fails, the attacker should land in a process with a narrow view of the filesystem, few privileges and a short list of permitted system calls.

Isolation is a property of the deployment as much as of the software. Whether the chroot jail, capability set and seccomp profile work as intended depends on how the server was installed, whether it runs in a container, and what the host or container runtime permits. A container may need extra privileges or relaxed profiles before the Kit process can set up its jail, and each relaxation weakens the containment you were relying on. Regulated teams should therefore ask Collabora which isolation mechanisms their chosen package or image uses, record the settings that apply in their environment, and confirm them during design and again after every upgrade, rather than assuming the defaults match their risk appetite.

Before go-live, plan a verification step that a reviewer can repeat. Confirm which Kit processes start for a test document, check that the process runs as an unprivileged user inside its jail, and check the effective capability set and seccomp status for that process. Record which exceptions were required to make the platform run, who approved them, and how they will be revisited when you move to a new release. Pair this with Collabora's release notes so that any change to isolation behavior in an update is reviewed before it reaches production.

Isolation controls and when each one fits

This table compares the isolation controls a team can keep, adjust or relax for Collabora Online Kit processes, from per-document processes through the container or host profile. Read each row for what the control contains, what it asks of the host or container, and when to keep it on. Exact keys and default behavior differ by release, so confirm them in Collabora's documentation before changing anything.

Control	What it contains and what it requires	When to keep it on
Per-document Kit processes	Each open document runs in its own Kit process, so a crash or exploit in one document's parsing does not directly expose other sessions. Requires enough memory and process limits to run several Kit processes per server.	Keep on in all environments. Relaxing it shares a parsing failure domain across users and is hard to justify for sensitive documents.
Chroot jails	Confine each Kit process to a separate filesystem view so it cannot read host paths outside its jail. Requires the host or container to allow chroot and to provide the jail's libraries, fonts and templates.	Keep on for any server that accepts documents from untrusted users or external WOPI hosts. Confirm the jail setup in the release notes for your version.
Dropped Linux capabilities	Remove privileges such as those for mounting or changing ownership so a compromised process has fewer kernel actions available. Requires the runtime to permit the reduced set and to avoid re-adding capabilities for convenience.	Keep on by default. Adding capabilities back to fix a startup error is a common silent weakening and should be reviewed.
Seccomp filtering	Limit the system calls Kit processes may make, which narrows the kernel attack surface. Requires a profile compatible with the Collabora build and the container runtime, and may break when a new feature or library is added.	Keep on in production. Switch to an unconfined profile only as a time-boxed diagnostic, and record the change and its approval.
Container runtime profile	Container defaults combine namespaces, seccomp, capability and resource limits into one profile. Requires the orchestrator to apply the profile to the Collabora pod and to prevent privileged mode and host namespace sharing.	Use for Kubernetes or Docker deployments where the platform team controls the runtime. Verify that the pod spec does not set privileged or unconfined options.
Host package install	Isolation depends on the host's kernel settings, the service unit and the AppArmor or SELinux policy in place. Requires the team to confirm the service runs with the expected user, limits and mandatory access control.	Use where containers are not available. Review the systemd unit and the security module policy after each package update, since defaults can change.
Relaxing controls for compatibility	Teams sometimes disable seccomp or chroot to get a feature, a font or a custom macro working. This removes the containment that protects against malicious documents.	Avoid. If a relaxation is unavoidable, limit it to a test environment, document the reason and the rollback, and re-test document handling afterward.

How per-document Kit processes contain a malicious file

A crafted document is meant to be contained by parsing it inside a separate Kit process, so that a compromise stays within that process's limited view of the filesystem, its reduced privileges and its allowed system calls. The containment logic depends on the process being the only thing that touches the hostile file. The server process and other sessions must sit outside that boundary, because a compromised Kit that can reach them could read or alter work it was never meant to see. Confirm the exact mechanics (which namespaces, chroot layout, capability set and seccomp profile your release applies) against the Collabora Online documentation for the version you run, since these details change between branches.

What a contained compromise still exposes is the content of the session it serves. An attacker who controls the parser can read the document being opened, any edits made to it during that session, and anything the Kit can see through its jail, such as fonts and temporary files. Containment limits the blast radius to that session, but it does not make the document's data safe. Plan for this by deciding which documents are sensitive enough to restrict in the integration, and by treating the Kit's jail contents as session data that must be cleared when the session ends.

Before you rely on this model, check three things in your own environment: that the jail and seccomp filters are active on the host or container you deploy, that the Kit runs under an unprivileged user, and that your container runtime does not grant extra capabilities or disable seccomp by default. Use the Collabora Online product page as the starting point for supported deployment modes, then confirm the details with Collabora for your release. Patching matters here too, because a parser flaw is the entry point that containment is designed to limit.

What the container or host must allow for Kit processes to start

Per-document Kit processes need a set of privileges from the container runtime or host before they can build their jail and filter their system calls. Each item below is a permission you grant or a restriction you keep, and each one that is missing tends to show up as a failed session start or a document that opens blank.

Privileges to build the chroot

Creating a chroot and the namespaces around it requires the process to set up its own root filesystem before it drops privileges. In a container, this usually means the runtime must permit the operations behind the jail, and a default profile may block them. If this is missing, sessions fail to start or the Kit process exits during setup. Confirm the exact requirement in the Collabora Online deployment notes and your runtime's security documentation, then test a session before you widen anything.

Capabilities granted and dropped

Kit processes are meant to run with a reduced capability set, and the container runtime decides which capabilities start with the workload. Granting broad capabilities to make the jail work removes much of the protection the jail was meant to add. Start from the minimum your runtime documents, add only what a failed start proves you need, and record each addition as an accepted risk.

System calls the seccomp profile allows

A seccomp profile filters the system calls a Kit process may make. A profile that is too strict blocks calls the office engine needs for file I/O, threading or rendering, which causes sessions to hang or documents to fail to load. A profile that is too loose defeats its purpose. Use the profile shipped with your Collabora Online version, and retest it after each upgrade because the required calls can change between releases.

Devices and mounts inside the jail

The jail needs read access to fonts, shared libraries and locale data, and it may need specific device nodes. Without the font directories, documents render with missing or substituted glyphs, which looks like corruption to users. Without the shared libraries, the Kit process fails at startup. Mount only the paths the engine needs, keep them read-only where possible, and confirm the list against the packaged layout for your distribution.

Resource limits for each Kit process

Each open document spawns a separate process that consumes memory and CPU, and a malicious or very large document can try to exhaust them. Container memory and CPU limits, and any process count limits, protect the host from runaway sessions but can also kill a legitimate large spreadsheet mid-edit. Size limits from observed concurrency and document size, not from defaults, and check the Collabora Online sizing guidance before you set them.

How to verify isolation is active on a test server

This sequence gives a test environment a repeatable way to confirm that Collabora Online starts, opens documents in separate per-document processes, and runs them with the restrictions the deployment was meant to enforce. It produces a dated record of what was observed on the exact release in use, which becomes the baseline for later changes.

Build a non-production test environment
The platform engineer installs the chosen Collabora Online package or runs the chosen image on a test host or cluster that mirrors the planned container runtime, kernel, storage layout and security profile. Use a version you intend to run in production, not CODE, and confirm the exact package name or image tag against Collabora's documentation for that release. Record the release, base operating system, container runtime and any seccomp, AppArmor or capability settings applied. The step is done when the server process is running under the service account you plan to use in production, and that configuration is written down.
Confirm startup and reported capabilities
The engineer starts the service and reads its startup logs, looking for messages that show the server initialized, which kit or jail mechanisms it detected, and whether it fell back to a less restrictive mode. Confirm the exact log text for the release in use, because wording changes between branches. Check the admin or health endpoint only if it is protected as planned. The step is done when the logs are saved and every warning about missing jail, capability or seccomp support has been either resolved or explicitly accepted in writing.
Open a test document from a test WOPI host
Use a test WOPI host, such as a test Nextcloud instance with Nextcloud Office configured to point at this server, and open a harmless sample document in Writer, Calc and Impress. Use the same protocol and hostname the production host will use so that the test covers the real request path. Open a second session on a different document from another test user so there are two concurrent sessions to inspect. The step is done when both documents load and the server log records a session for each.
Check that each session has its own process
From the host or container, list the child processes of the Collabora Online server and match each document session to a separate kit process. Confirm that the processes run under an unprivileged user rather than root, and that the two sessions do not share one process. Note the process IDs, parent process and owner for each session. The step is done when there is a one-to-one mapping between open sessions and kit processes, and closing a document removes its process.
Inspect the filesystem view and capability sets
For each kit process, review the root filesystem it sees (for example through the process root link under /proc, or by running a read-only listing from inside the jail if the release supports it) and confirm it contains only the files the jail is meant to expose. Read the effective, permitted and bounding capability sets from the process status file and compare them with the minimum you documented for this release. Confirm the exact paths and capability names with Collabora's guidance for your version. The step is done when every capability outside the documented minimum is absent and the jail root matches the expected layout.
Verify seccomp filtering and blocked system calls
Read the seccomp mode for each kit process from the status file, expecting filter mode rather than disabled. Confirm which filter profile is in effect and whether the container runtime applied its own profile on top. Attempting a disallowed system call from inside a test process is a stronger check, but it should only be done with a test build or a process you are authorized to probe, and the expected failure should be confirmed for the release in use. The step is done when the filter mode is recorded for every kit process and any observed denial matches the documented profile.
Record the baseline and repeat after each change
The engineer saves the logs, process listings, capability sets and seccomp modes as a dated baseline, labeled with the release, configuration and test document set. Repeat the same checks after every upgrade, change to the container image or seccomp profile, or change to the host kernel. Compare results against the baseline, and treat any missing jail, extra capability, or disabled filter as a failed check that blocks promotion. The step is done when the baseline is stored with the deployment record and the repeat procedure is written into the runbook.

How isolation differs between Docker, Kubernetes and host packages

With the Docker image, the image sets the starting point, but the runtime profile is whatever your container engine and orchestration files apply when the container starts. You own the docker run command or the Compose file, so every capability, seccomp or AppArmor setting is either a decision your team made or a default you inherited without review. Collabora's free CODE edition is suited to testing and is not recommended for production, so confirm which production image and tag your team is using and what Collabora currently documents for it before you build controls around it.

Who controls the profile: your team does, through runtime flags and the Compose file, not the image alone.
Privileges the container needs: confirm whether your engine version needs extra capabilities or relaxed syscall filtering for the chroot setup, and record the answer in your configuration.
Default seccomp profile: confirm whether your engine applies its default profile and whether any override in your files weakens it.
Privileged mode: do not treat --privileged as a shortcut. If a fix seems to require it, treat that as a finding to narrow down to specific capabilities.
Filesystem and resource limits: test whether a read-only root filesystem and resource limits still allow documents to open, edit and save.

Before relaxing any default, test with a known-safe document and a sample you have approved for security testing in a non-production environment, and record which setting changed the result.

On Kubernetes, the runtime profile is shared between the cluster administrators and the chart values you deploy. The official Helm chart README gives production resource guidance of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Those values are sizing inputs for scheduling and capacity. They say nothing about containment, and they should not be read as evidence that the pod is isolated. The same README states that horizontal pod autoscaling is disabled and that load balancers must route by the WOPISrc parameter so all users editing one document reach the same pod. That is a session requirement, not a security control.

Who controls the profile: the cluster team, through pod security enforcement, and the platform team, through chart values and overrides.
Security context: confirm which capabilities, seccomp profile and privilege escalation settings the chart sets for the version you deploy.
Pod security enforcement: check whether your namespace policy blocks any privilege the pod needs, and whether it fails quietly or blocks the rollout.
Overrides and drift: record every value override, because a later chart upgrade can change defaults you assumed were still in place.
Routing and replicas: keep replica counts managed by hand and confirm the ingress routes by WOPISrc so editing sessions stay on one pod.

Before deployment, render the manifests from the chart with helm template and compare the security context against your admission policy.

Risks of weakening isolation to get a deployment working

When a document fails to open or a container refuses to start, the fastest fix often removes a containment layer. Each shortcut below trades a visible error for a larger attack surface, and each has a safer test to run first.

Running with broader privileges

Teams add --privileged or extra Linux capabilities to clear a chroot or namespace error. That lets a compromised Kit process reach far more of the host than the default container allows. Check the container runtime flags and the pod security context for privileged mode or added capabilities. Test first by adding only the single capability the error names, then keep the rest dropped.

Disabling the seccomp profile

Setting the seccomp profile to Unconfined, or removing the seccomp option altogether, lets a malicious document reach system calls the editor never needs. A failing system call usually means a missing filter entry or a kernel difference, not a reason to drop filtering. Inspect the container spec for seccompProfile or seccomp=unconfined and confirm the profile is still loaded. Test first by logging denied calls and adding only the one required.

Adding host mounts

Mounting host directories such as /etc, /proc or a shared document store into the container to fix font, template or path errors exposes host files to the document process. A parsing flaw then has a route to data outside the jail. Review volume definitions and bind mounts for any path outside the Collabora data and font directories. Test first by packaging the missing fonts or files into the image or a read-only volume with no host path.

Running as root

Running the server as root often appears to fix permission errors on mounted volumes or sockets. Root inside the container makes escape from the jail far less costly, and it turns any file write into a host-level concern. Confirm the effective user with a process listing and check the image's USER directive. Test first by correcting ownership of the mounted paths for the service user and keeping the process unprivileged.

Sharing one process across users

Routing several tenants or customer groups through one long-lived Kit process to save memory or simplify routing removes the per-document boundary that isolation depends on. A malicious document can then affect other people's open files in the same session. Ask whether your sizing plan counts separate Kit processes per document and whether any load-balancer or proxy rule mixes tenants. Test first by checking concurrency settings against the sizing guidance before adding capacity by sharing.

Running CODE in production

The free CODE edition is a rolling release recommended for testing, home use or small teams, not for production. Production use means patches arrive on Collabora's rolling schedule without the support and signed updates a subscription provides. Check the image tag and package source against the CODE page and the subscription terms. Test first by moving to a supported Collabora Online release and applying advisory fixes on a staging copy.

Keeping isolation intact through patches, upgrades and new formats

Isolation settings drift unless someone owns them. A chroot jail, dropped capabilities and a seccomp profile are only as good as the image, package set and runtime they were tested against. A rebuilt container image, a package manager pulling a newer dependency, or a new Collabora Online release can quietly change which system calls, mounts or capabilities the Kit processes need. Treat the verified configuration as a versioned artifact: pin the image tag or package version you tested, store the seccomp profile and container security context in the same Git repository as the deployment manifests, and record which Collabora Online release the verification was run against.

Re-run the same isolation checks after every minor release and before every rebuild. Confirm that a Kit process still starts with its chroot and reduced capabilities, that a document that exercises unusual parsers still opens and saves, and that the system logs show no new seccomp denials. Read each Collabora security advisory for sandbox or parser impact, not only for the headline issue. The 25.04.7.5 release, which fixed CVE-2026-23623 according to the Collabora Online 25.04 release notes, is a useful example of why the advisory text matters: a fix in document parsing is exactly where a sandbox is tested. If an advisory touches the Kit or its file loaders, rerun the verification before rollout rather than assuming the patch leaves isolation unchanged.

Keep package trust current as well. For RPM and DEB installs, the same release notes record that package signing keys were updated, so signing key rotation is part of routine maintenance, not a one-off task. Ask Collabora to confirm its advisory and patch schedule, the notice period for signing key changes, and which channel delivers security notices to customers. When you add a new file format or enable a feature such as the optional AI assistant in 26.04, treat it as a change to the isolation baseline and verify it the same way. Confirm with Collabora whether a new feature needs additional capabilities, mounts or filters before you enable it in production.

Limits to confirm in your environment before you rely on isolation

Process isolation only protects you if the release, the runtime and your policies all allow it to work as designed. The cards below list the items to confirm before you treat chroot jails and seccomp filtering as a containment layer for untrusted documents.

Isolation mechanisms in your release

Confirm which isolation features the exact Collabora Online build you run actually enables, including whether per-document Kit processes are chrooted, which capabilities are dropped and whether seccomp filtering is active. Check this on a running instance, not only in the documentation for the branch. Record the result for each version you deploy, because a minor release or a packaging change can alter the defaults. Verify the running process, not the intent.

Privileges the runtime permits

Check whether your container runtime, managed Kubernetes platform or hardened host allows the capabilities and mount operations that chroot setup requires. Pod security policies, admission controllers and default seccomp profiles can silently block these operations or force the service to run with weaker settings. Ask the platform team to confirm the exact privileges granted to the Collabora Online workload, and whether any exception has been granted that widens them.

Fonts and bundled resources

Confirm that fonts, templates, dictionaries and other resources the editor loads are available inside the jail or container view. Missing paths can cause rendering failures that teams mistake for isolation problems, and the temptation is to loosen the jail to fix them. Test representative documents with your corporate fonts and templates, and review every bind mount you add to close those gaps.

Security tooling and syscall policy

Confirm whether endpoint protection, runtime security agents, audit tools or enterprise hardening baselines block or log the system calls that the seccomp filter and Kit processes use. Blocked calls can crash document sessions, and overly broad exceptions remove the filtering benefit. Ask your security team to review the syscall allowances against the policy in place and document any exception with an owner and a review date.

Evidence that auditors accept

Confirm with your assessor which evidence you will present to show that isolation is enabled and monitored, such as configuration captures, container specifications, startup logs and test results with a hostile sample file. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors decide whether that evidence satisfies a given control. Agree the evidence format before the assessment window opens.

Vendor support and version scope

Confirm what your support agreement with Collabora covers for the version you run, including whether security fixes to the isolation code arrive for your branch and under what plan. Community builds such as CODE are rolling releases and are not recommended for production, so the support boundary changes with the edition. Put the branch, the edition and the patch cadence in writing before you rely on this layer.

Questions teams ask before they change Collabora Online isolation

Can we turn off chroot jails and seccomp for Collabora Online safely?

Not as a routine setting. Chroot jails, dropped capabilities and seccomp filtering are the layers that contain each per-document Kit process if a malicious or malformed document exploits the office engine, so disabling them removes containment that the rest of your configuration assumes is present. Some container platforms block the system calls or namespace features these layers need, and the usual fix is to widen the container or host policy, not to switch the protection off. Any loosening should be a documented, reviewed exception, tested against a copy of your production document set, and reversed once the cause is fixed. Confirm the exact settings for your version in Collabora's documentation before you change anything.

Do we need a partner to configure process isolation?

No, a capable platform or security team can configure it, provided it has container or host access, a way to test document opening and editing, and time to verify the result. A partner mainly adds value when the team lacks experience with Linux namespaces, container security profiles or Kubernetes pod security settings, or when the review must produce evidence for an assessment. DeployOpen plans, implements and documents this work in infrastructure you control, and the written scope sets out who does which step before work starts.

How much effort does a hardening review take, and what drives it?

Effort depends on how the server is deployed and how many controls you need to verify. Docker images, system packages and Kubernetes each place the chroot and seccomp requirements in a different layer, so the review starts with mapping your deployment. The main drivers are the number of hosts or pods, whether you run the built-in CODE app or a dedicated server, how much custom seccomp or AppArmor policy already exists, how many document types you must test, and whether results must be documented for an auditor. Ask any provider for a written breakdown of these drivers and for the deliverables each one produces.

What does the work need from our internal team?

Plan for three things. First, privileged access to the container runtime or host, including the ability to read the effective security profile and restart the service in a change window. Second, a test WOPI host, such as a non-production Nextcloud instance, that can open and save representative documents against the test Collabora Online server. Third, a scheduled change window with a rollback plan, because a policy that blocks a required system call can stop document loading for every user. Your team also needs a named owner to accept the results and keep the policy under version control.

Can our team handle the isolation work without outside help?

Often yes, if the team already runs Linux containers in production and can read seccomp and capability settings. Work through the deployment guidance, reproduce the failure modes on a test server, and keep a record of each change. Where the team is new to these controls, budget time for learning and for a second review before production. Whatever the approach, confirm the supported configuration for your Collabora Online version with the vendor, because platform defaults change between releases.

How does process isolation relate to WOPI allow lists and TLS?

They protect different points in the same path. WOPI host allow lists decide which storage hosts can open documents, proof keys verify that requests really came from the host, and TLS protects traffic in transit. Process isolation limits what happens after a malicious document reaches the server, so it is a separate layer. A strong allow list does not stop a hostile file that a trusted host uploads, and isolation does not stop an unauthorized host from connecting. Review all of these together, and treat any change to one as a reason to recheck the others.

What should the review deliver?

Ask for a written record of the effective isolation settings in each environment, a list of any exceptions with the reason and an owner for each, test results for opening and saving your representative document types, and a rollback procedure. Also ask how the policy is kept under version control and rechecked after each minor release. Patching and advisory tracking belong in the same operating routine, because a new release can change the profile the server needs.

How DeployOpen scopes and delivers Collabora Online isolation work

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, including Collabora Online process isolation with chroot jails and seccomp. The work starts with a written scope that defines which containment controls apply to your deployment model, what your container or host must permit, and how the result will be verified.

How we scope

Confirm whether Collabora Online runs from Docker, system packages or Kubernetes, since isolation controls differ by deployment model.
Record the kernel, container runtime and seccomp profile constraints your platform team must support before any build starts.
Agree in writing which isolation tests, documentation and handover items are in scope, with engagements fixed-scope by default.

How we build

Configure chroot jails, dropped capabilities and seccomp filtering for per-document Kit processes in the environment you specify.
Document each syscall, capability and mount the deployment requires, and explain the security effect of every relaxed setting.
Test that a malicious or malformed document is contained inside its process and that disallowed system calls are refused.

How we hand over

Deliver a configuration record covering the container or host settings, the seccomp profile, and the reasons for each exception.
Provide a runbook for checking isolation after upgrades, since Collabora Online patch releases can change process behavior.
Walk your platform and security teams through the verification results and the list of risks accepted by your organization.

How we support

Re-run isolation checks when you move to a new Collabora Online branch or change the container image or host kernel.
Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing for your environment.
Prepare evidence of isolation controls for internal reviews and compliance assessments, while independent auditors issue any formal opinion.