In Part 2, we continue revealing Collabora’s multi-layered ‘security onion’ by exploring the architecture of Collabora Online’s three main processes.

We explain how the architecture isolates each document within its own secure container, strictly limiting system calls and filesystem access through technologies such as Seccomp-bpf.

CoolWSD is the only process that communicates with the outside world and handles client network connections, manages user input routing, and securely communicates with external storage using encrypted tokens.

CoolWSD controls a helper process called CoolForKit. This component never interacts with or opens documents directly; instead, it pre-loads core software libraries into memory and rapidly forks itself to spin up individual CoolKit document instances.

To lock down the system, CoolKit runs inside a “chroot jail” that completely isolates it from the host machine. This environment operates as a sparse filesystem that contains no system shells, no core system directories, and strictly limits kernel API system calls to enforce the principle of least privilege.

Read Part 1 where we explain how Collabora Productivity’s security strategy is built on organisation compliance from our ISO 9001 and ISO 27001 certifications and large-scale continuous automated crash testing, fuzzing and regular static code analysis.

A Many Layered Security Onion

Security is a core consideration for Collabora Productvity, flowing from our internal processes to informing our software design and technical architecture through to our software development implementation, continuous testing, security reporting and support. In Part 2, we highlight our security strategy for software design and technical architecture.

If you missed Part 1 of this series you can read it here, we cover Collabora’s organisation compliance and large-scale continuous automated testing.

The design of Collabora Online’s architecture involves a multi-layer security strategy to make it as secure as possible out-of-the-box. Why is this important? While it is possible that a problem in the software at one layer enables some negative foo, because a situation would need to chain problems together to breach all of the layers we can dramatically reduce the probability, and ensure your systems remain safe while we fix any individual layer problems.

The Three Main Processes

COOL’s self-contained architecture is made up of three groups of processes:

• Cool Web Service Daemon (CoolWSD)
• CoolForKit (named after its function to ‘fork Kit’)
• CoolKit

In very broad terms, CoolWSD is the ‘master’ or ‘broker’ process that handles and routes network traffic. CoolForKit is a ‘helper’ or ‘forker /spawner’ process controlled by CoolWSD that optimises creating document processes by pre-loading and sharing the core libraries and before rapidly forking itself to provide instances of CoolKit – the ‘document engine’, that isolates and contains each document from other documents.

CoolWSD

CoolWSD is the only process in COOL that communicates externally. It is responsible for spawning CoolForKit, setting up the childroot directory for documents and listening on the public port (9980, by default) for client connections and routing user input (for example, when a user opens a document and a ‘load ‘ command is sent).

COOL uses isolated per document processes, which start when CoolWSD requests CoolForKit to ‘fork itself’ to create a Kit instance for each document. CoolForKit finds the CoolKit, based on a unique key, and sends on the CoolWSD request to the Kit instance to load the first document view.

CoolForKit

As mentioned above, CoolForKit is primarily an optimization responsible for forking Kit instances. It does this by loading up Collabora Office dynamic object libraries (DSOs) into memory and pre-initializing all of the data we will need inside the Kit processe to ensure these will be Copy on Write shared. To make loading of documents faster CoolForKit forks Kit instances ahead of time (based on a prespawn config setting) and stands ready to fork more instances when requested by CoolWSD.

CoolKit

The CoolKit process is the fundamental core of our document editing engine. It is responsible for loading and rendering documents and for passing input and commands from users to the document and, similarly, for passing document events (e.g., a user typing etc) generated back to the client.

The Kit process contains the eight million lines of C++ code that comprises most of our attack surface, and as such we add many more layers of the security onion around it.

As the main three processes in Collabora Online demonstrate, our multi-layered security architecture is designed to be as secure as possible, approaches using strict isolation, container jails (chroot) and the principle of least privilege.

In Part 3, we explore Collabora Online’s WOPI-like protocol and our approach to storage, we look at how server-side tile rendering keeps your documents secure, and highlight how our dedicated security engineers continuously work to improve security every day.

Evaluate Collabora Online for your organisation today. Try a pilot deployment of a document editor; obtain enterprise-grade protection straight out of the box so your organisation can collaborate with total peace of mind.

The post Finding a Secure Document Editor for Your Organisation Part 2 appeared first on Collabora Online and Collabora Office.