Ubuntu Core as an immutable Linux Desktop base

Canonical began the development of Ubuntu Core in 2014, to create a fully-containerised platform for IoT. In Ubuntu Core, we use the same kernel container technology that Docker and LXC are built on, to put every component of the system into a secure sandbox, with well-defined upgrade and rollback. We did this to enable autonomous connected Internet of Things  devices to receive updates which they could apply without human intervention, to address security and business needs at the edge. Ubuntu Core’s minimal footprint lends itself to enabling a secure, resilient, evergreen operating system that can be relied upon in the most challenging environments.

The containerised approach means that each piece of the system is tamper-proof and can be updated cleanly and independently. It means that you can run apps which you don’t trust to see everything on your system, you only trust them with the data they themselves are supposed to manage. And it means that you have much more flexibility to use newer versions of apps on older versions of Linux. Ideally, it means that a publisher can publish an app which works well on every desktop.

Desktop software is in many ways trickier to containerise than server or IoT software, because we want our desktop apps to work well together. That tight integration also makes it more difficult to define the sandbox boundaries between applications and system components in a way which is both secure and easy to use. Snaps are a little famous for having some rough edges on the desktop 🙂 Nevertheless, we are excited to explore the idea of a fully containerised desktop, where each component is immutable and isolated. We have steadily been improving the experience of desktop snaps. And in due course, when we think the entire system can be delivered this way, we will be excited to offer a version of the Ubuntu Desktop which has these new capabilities.

In this blog post we discuss the architecture of immutable operating systems, their benefits and drawbacks, and the role of Ubuntu Core in the immutable Linux landscape. We demonstrate how its focus on composability and security brings unique benefits to IoT, edge, robotics and cloud developers. 

We’ll also cover the rise of immutable Linux in the desktop, the advantages to users and the role Ubuntu Core could play in its future… strap in!

What is an immutable operating system?

Before we can discuss what differentiates Ubuntu Core from other immutable operating systems, we must first define the properties that make an OS immutable:

1. Read-only: The primary characteristic of an immutable OS is that the running system cannot be directly modified by users or applications.
2. Atomic updates: Updates are applied atomically; meaning they’re successfully applied all at once or not at all.
3. Predictable: Because the core operating system doesn’t change, its behaviour is predictable across devices.
4. Isolated Applications: Applications are isolated from the core operating system and from each other, usually through containerisation. This ensures that changes made by an application don’t affect the core system or other applications.

What are the benefits?

1. Security: It is more difficult for malicious software to make changes to the system or to spread from one application to another.
2. Stability: System files cannot be altered or deleted by accident and atomic updates ensure that system updates do not leave the system in a partially updated and potentially unstable state.
3. Reproducibility: Because the OS is identical from boot to boot it is easier to test, audit and verify the system, as well as diagnose and troubleshoot issues.
4. Manageability: Since each instance of the OS is identical, system administrators do not have to worry about unexpected changes or inconsistencies between different systems. Atomic updates and rollbacks simplify the process of applying system updates and fixing issues.

What are the drawbacks?

1. Reduced Flexibility: An immutable OS is less flexible than a traditional OS. Users cannot modify system files or customise their system to the same degree.
2. Limited Compatibility: Not all applications and services are compatible with the containerised or isolated environments provided by an immutable OS. 
3. Storage Requirements: Update mechanisms often require image snapshot storage. Isolated applications can lead to redundancy in the storage of application dependencies.
4. Developer Experience: While containerised development environments provide benefits (such as improved isolation and reproducibility) they may also introduce additional complexity and limit the use of familiar tools and workflows.

Immutable operating systems are particularly well suited to environments where stability, security, and predictability are paramount, such as servers, IoT devices, and high-security environments. However in recent years we’ve seen these properties demonstrate significant user value, first in the mobile OS space and increasingly in the PC space.

The architecture of an immutable Linux OS

Now that we’ve defined these properties, let’s review the design choices made in today’s immutable Linux ecosystem.

Chrome OS

Outside of mobile, the OS that has most effectively popularised the value of immutability for daily users is the Linux-based Chrome OS, designed with a cloud-first approach to productivity and development.

Chrome OS prioritises security with a read-only operating system, sandboxed applications and processes alongside hardware-backed encryption. Verified boot confirms that the system has not been modified via firmware and kernel signature checks at each stage of the boot process.

Updates are handled via an ‘A / B process’ where the device stores two versions of the operating system: one that is actively running and a second that is inactive, but to which modifications and updates can be applied in the background. If those modifications are successfully applied then the new version is automatically selected on the next reboot.If not, the device boots back into the existing image, making updates much more resilient.

Fedora Silverblue and OSTree

Recent immutable Linux distributions like Fedora Silverblue follow a similar upgrade mechanism to Chrome OS via a tool called OSTree. With OSTree, full system images are downloaded in the background when an update is available and users can simply boot into them once installed.

OSTree stores snapshots of the system when changes are applied. During boot the user is presented with a list of these snapshots allowing them to boot into any of them — effectively rolling back the system. This update and rollback mechanism mitigates instability that may result from users modifying their OSTree. The result is that users can confidently layer applications, or even graphics drivers, into the OS snapshots. OSTree minimises the storage and bandwidth overhead of system updates by only shipping “deltas” (differences) in each revision.

MicroOS and Btrfs snapshots

openSUSE’s MicroOS, like Ubuntu Core, was designed primarily for IoT and other single purpose use-cases. However,it now supports a full desktop environment named openSUSE Aeon. MicroOS uses Btrfs snapshots, cloning the current running root filesystem to apply updates and then marking the new root filesystem as the next boot target. While this is a different approach to OSTree, using Btrfs snapshots also optimises the storage requirements that come with maintaining multiple bootable system images due to its copy-on-write operation.

Containerised applications

While rebooting after a system update is often preferred because underlying changes can affect running applications or services, placing the same requirement on application upgrades is undesirable because it can lead to unnecessary disruption in the operation of the system.

To resolve this, the immutable OS’s mentioned above take advantage of containerised desktop applications (Docker, Flatpak, etc.) that run independently of the base-OS, and are not considered as part of the OS filesystem. This enables a controlled level of mutability for those applications and services that are not considered critical for the system to boot (and be managed). Such a mechanism allows applications to be updated on their own cadence without the need for a reboot and without compromising the resilience of the underlying system.

Snaps

Snaps are also immutable applications. When a snap is installed, it arrives as a complete, self-contained package that includes the application and all the dependencies it requires. These elements are bundled together into an immutable squashfs filesystem. This means that “snapped” software doesn’t modify or depend on the host system’s libraries or settings, resulting in consistency and predictability across hosts. 

During the upgrade process for a snap, the entire package is replaced atomically and user data is copied between versions, ensuring that the application is always in a consistent state, thereby reducing the risk of issues often introduced by partial updates. 

Snaps also provide additional security benefits through ‘strict confinement‘ and a robust signing and verification process. When a developer uploads a snap to the Snap Store, it is signed with a key registered to the developer’s account after a detailed security review. When a Linux distribution running snapd downloads and installs a snap, it verifies the signature against the Snap Store’s public keys. This ensures that the snap hasn’t been tampered with and that it originates from a trusted source.

How Ubuntu Core combines immutability with composability

The technology behind snaps extends beyond the distribution of desktop applications however. With Ubuntu Core this philosophy of security and stability applies equally to the components that make up the entire Ubuntu operating system.

Rather than treating the OS as a single immutable ‘blob’, Ubuntu Core breaks it up into discrete components. The base of Ubuntu Core, for example, is built on four primary snaps:

• Gadget: Defines the system’s bootloader, partition layout and default configurations for snaps.
• Kernel: Containing the Linux kernel and hardware drivers.
• Base: A minimal Ubuntu OS image containing only the necessary services and utilities to support the applications running on top.
• Snapd: Manages the lifecycle of all snaps in an Ubuntu Core system.

Additional OS snaps can then be layered onto this image to enable other elements of the operating system such as a desktop environment (more on this in the next section).

Even more atomic

This composable approach to building an OS brings a number of key benefits. In the first instance users can assemble streamlined Ubuntu Core images with only the necessary components needed to run single purpose applications, minimising both the OS footprint and potential attack surface.

The other benefit is that any snap type can update on its own cadence, significantly reducing the need to reboot your device. Rollouts (and rollbacks) are more granular, allowing updates to the networking stack, for example, to run at a different cadence to the kernel.

How channels create additional flexibility

Another feature of snaps is the use of channels for delivering updates. Each snap has four standard channels: stable, candidate, beta, and edge. These channels allow users to choose how cutting-edge they want their software to be. The stable channel is the most tested and reliable, while the edge channel includes the latest changes from the application publisher. This model allows users to opt into the risk level that they’re comfortable with.

Channels also enable phased rollouts and easy rollbacks. Developers or administrators can push updates to a subset of users for testing before rolling them out to everyone. If an issue is discovered with an update, it’s easy to roll back to a previous version. This can be done on a snap-by-snap basis, minimising disruption to the system.

The potential of Ubuntu Core for Linux desktops

Behind the scenes, the Canonical team has been actively exploring the benefits of Ubuntu Core beyond the realm of IoT, most notably in the context of developers and daily users.

The properties inherent to Ubuntu Core such as secure boot, recovery states and hardware backed encryption would bring significant improvements to the security posture of a user’s PC.

It also introduces the concept of modularity to the user experience, where users may experiment with alternative desktop environment snaps while remaining on a highly stable, signed and secure LTS base.

The use of snap channels also brings into the play the concept of ‘rolling’ certain elements of the distribution. Gamers, for example, might opt-in to a kernel channel that ships the latest NVIDIA drivers as soon as they are available, in the same way the Ubuntu Desktop team did for Mesa as part of our work on the Steam snap.

However, this level of stability and security comes with trade-offs for developers and tinkerers, restricting modification of the base OS in favour of a ‘just works’ experience. For developers who see their device as a platform for open source development, the solution is container-based environments similar to the LXD based Crostini. For tinkerers, the classic Ubuntu images would remain their preferred route to enable full control of (and responsibility for) their system.

Find out more

Over the next few months we’ll take a deeper dive into the philosophy behind Ubuntu Core and its future applications. To stay up to date, sign up to our newsletter at the side of this page.

In the meantime, check out the following links for more information:

• ubuntu.com/core for a summary of the features of Ubuntu Core.
• ubuntu.com/core/stories to read how Ubuntu Core is used today in networking, agriculture, robotics and drone applications.
• ubuntu.com/tutorials to try Ubuntu Core for yourself.