Note: Post archived from previous website - some links, images, and/or post formatting may not display correctly. Contact us using the contact page below if you have any questions about post contents.
Ensuring the utmost security of your documents and data is paramount. Collabora Online, a powerful document editing solution, goes above and beyond to fortify your security, providing you with a robust shield against potential threats. In this blog post, we’ll delve into some of the central security features that make Collabora Online the trusted choice for so many – including Seccomp BPF, Sparse File Systems, and Chroot. These are the pillars upon which our security stands. We’ll explore how these technologies work together to create a document environment that’s not only highly efficient but also exceptionally secure.
It is worth noting, in order to enact some these security measures, Collabora Online requires enhanced privileges to start with in order to limit access to the rest of a system. These are swiftly dropped after they are used to lock-down each document. This methodology may seem paradoxical at first, but we hope that in this post you will see why these widely-recognized industry-standard1,2 security layers, in fact bring about the greatest safety for your file storage and editing solutions.
Seccomp BPF
Seccomp BPF is a Linux kernel feature that enhances security by restricting the system calls a process can make3. This technology significantly reduces the total kernel attack surface, minimizing the risk of potential security breaches. It lets us shrink the access of Collabora Online document processes to system calls that have been problematic in the past4. All unexpected requests can then be instantly recognized as a malicious attack and cause immediate termination of the the relevant document process by the operating system.
One example threat that this eliminates would be an escaped application attaching a hand-crafted debugger (using the ptrace system call) to try and access data or disrupt other system operations. In this instance however, the use of ptrace or ‘kill’ system calls would be immediately recognized as illegitimate, not performed, the attempt logged, and the document immediately terminated.
As mentioned in the introduction, in order to provide this layer of protection, Collabora Online requires sysadmin capabilities, however these are rapidly dropped after startup, and provide one of the strongest security pillars. By enabling Seccomp BPF within Collabora Online containers, partners can rest assured that their document environment remains safeguarded from a whole set of malicious activities.
Chroot
Chroot, short for “change root,” is a mechanism that runs a process and its children within a confined directory, isolating them from the rest of the system. Integrating Collabora Online with chroot ensures that the application and its dependencies are enclosed within a controlled environment, minimizing the potential for conflicts with other software, and again ensuring any security breaches are isolated by default, greatly reducing the possibility of any system-wide disruption.
What this means in Collabora Online is that every document user is only able to access the document data served to them in the first instance, and cannot acquire access to the rest of the system files, or use the file-system to communicate or disrupt other documents. Similar to the way fire doors are used to prevent the spread of a fire through a building, except in this case the door is fireproof, and there is no key.
Sparse File Systems
Collabora Online has been optimized in many ways to streamline resource utilization whilst bolstering security measures at the same time. One key security optimization is the sparse file system setup.
With a sparse file system setup, Collabora Online minimizes its footprint by exclusively installing the libraries and fonts essential for operation. Unlike other installations that may include unnecessary elements, this streamlined approach both saves on system resource usage, and as with Seccomp BPF above, further reduces the potential system attack surface area.
Examples of exclusions from the Collabora Online chroot would be shell tools, or unnecessary device nodes. By heavily restricting access to system device nodes Collabora Online operates with a very limited set of resources, making it very difficult for any attack to develop within the system. Following on in the fire safety analogy, this would be like removing flammable materials from a building to prevent fires starting or spreading.
In order to remove unnecessary and potentially dangerous functionality from the Collabora Online chroot, enhanced privileges are required. As mentioned above however, this privilege is dropped rapidly after entering the chroot. By only incorporating the resources that are absolutely necessary, Collabora Online further fortifies your system against potential security breaches.
Sharing memory
So why does Collabora need its own containment system? In short – for memory efficiency.
Technologies like Copy on Write (COW) and virtual memory sharing are essential components of Collabora Online’s resource-efficient yet highly-secure environment. When documents are opened in Collabora Online, COW enables multiple users to safely share large parts of the same memory space. This seriously cuts down on time and system resource usage, since other than the content unique to each document, the majority of each Collabora Online instance can be shared.
Given the above warnings about chroot and sparse file systems, this might seem like we are contradicting ourselves, but in this case the reality is that the shared components are only ever framework components, and due to the way COW functions, the new document ‘sharing’ another’s settings has no access to the actual sensitive file data, nor even the ability to modify the shared data from the original file. The key to COW’s speed and efficiency, is that only if/when the framework data is modified (written – as in Copy on Write), is an actual copy created, and new bytes written.
So why bother? Because COW is perhaps analogous to utility supplies, or other public services provided to houses or offices. Not using COW, and re-building the framework data for every document, would be like building new power stations, water treatment works, gas storage facilities, hospitals, schools, train stations, bus stations and road networks for every single house. This is of course not done, and you don’t hear of businesses complaining about the security implications of sharing a water supply with the neighbours.
In the same way, virtual memory allows the majority of memory used to be efficiently shared between containers. The Linux operating system provides strict isolation mechanisms to prevent any write access to another user’s code or document data.
This strikes a well-optimized balance between resource usage and robust security, bringing down the un-shared data cost for each document from perhaps 300Mb to 25Mb. In this way, collaborative working in Collabora Online can remain efficient, all the while safeguarding the privacy and integrity of each user’s data.
Additional security practices
Document editors are substantial applications, and Collabora invests heavily in hardening the LibreOfficeKit core, which forms the foundation of Collabora Online, and comprises over 8 million lines of code. In addition to the security pillars outlined already, further rigorous measures are in place to uncover any issues. These include crash testing, use of COVERITY5, and aggressive fuzzing in partnership with Google’s OSS-FUZZ6.
Crash testing involves subjecting the software to various stress tests and scenarios to uncover vulnerabilities that could lead to crashes or security breaches. COVERITY, a sophisticated code analysis tool, is deployed to scrutinize the code base for potential flaws or vulnerabilities. Complementing these measures is aggressive fuzz testing, where the software is bombarded with a wide range of unexpected inputs to discover and rectify any weak points.
The size of the core code remains the top attack vector, and we work hard to ensure that no code can break out and execute inside the context of the document. This however is why the above protective layers are key to ensuring the highest levels of security for your document editing solution.
Is it just us?
System administrators are rightly cautious when alerted to requests for enhanced permissions, but the reality is that this remains one of the best ways to lock down an application. Google Chrome in Linux for example is also a set-uid program. Other server-side software like Jitsi or Postfix also doesn’t drop all capabilities for similar reasons. Other app containment and sandboxing systems such as Flatpak employ the same strategy of running with elevated privileges to employ specific security measures like Seccomp BPF and utilize sparse file systems. This approach, which ultimately limits the program’s reach and ensures that potential vulnerabilities don’t lead to widespread damage, is a widely recognized and accepted industry practice.
Conclusion
Collabora Online is architected from the ground up to safeguard your documents and data while providing a feature-rich and efficient document editing environment. Operating with enhanced permissions, Collabora Online will ensure you have the best security measures available at your disposal, making sure your digital workspace remains safely locked down.
If you give Collabora Online the permissions it needs to do the job well – you will be much safer.
Keep your data secure with Collabora Online.
Collabora Online – Safe, Powerful, Flexible.
1https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/container_security_guide/linux_capabilities_and_seccomp
3https://www.kernel.org/doc/html/v4.16/userspace-api/seccomp_filter.html
A large number of system calls are exposed to every userland process with many of them going unused for the entire lifetime of the process. As system calls change and mature, bugs are found and eradicated. A certain subset of userland applications benefit by having a reduced set of available system calls. The resulting set reduces the total kernel surface exposed to the application. System call filtering is meant for use with those applications.