A couple of weeks ago, we talked about snap security, taking a journey through the eyes of a developer and handing over to a user who wants to install applications from the Snap Store. We discussed concepts like application confinement, interfaces, store review, and automatic updates. Today, we will look under the hood, and examine the underlying security mechanisms, and then talk some more about Ubuntu Core.
Ubuntu uses several security hardening mechanisms, including: Discretionary Access Controls (DAC), Mandatory Access Control (MAC) via AppArmor, Seccomp kernel system call filtering (limits the system calls a process may use), cgroups device access controls for hardware assignment, and pseudoterminal (PTY) functionality for login sessions via a new devpts instance per command to prevent snooping and input injection via /dev/pts. Ubuntu also uses YAMA Linux Security Module in Canonical-supported kernels, and provides ptrace scoping, symlink restrictions and hardlink restrictions.
The DHCP client runs under a restrictive AppArmor profile.
The administrative user (root) has a disabled password. All system users have disabled logins.
When installed on desktop and server, OpenSSH listens by default but it is configured with PermitRootLogin prohibit-password to disable root logins when a password is set. For Ubuntu on cloud, this is the default configuration.
The name of this subsection can be a little confusing, because the FHS applies to snaps used both on classic Ubuntu as well Ubuntu Core. The snap installation directory is read-only, with specific writable data areas. These areas correspond to environment variables that are set during runtime. Specifically:
$SNAP(versioned install path)
$SNAP_DATA(versioned path in /var)
$SNAP_USER_DATA(versioned path in /home)
$SNAP_COMMON(snap-specific path in /var)
$SNAP_USER_COMMON(snap-specific path in /home)
$XDG_RUNTIME_DIR(snap-specific path in /run/user/”uid”)
Furthermore, there are several confinement mechanisms enabled in Ubuntu (snaps):
Ubuntu Core is a lightweight, robust, transactional version of Ubuntu for IoT devices and large, scale-out container deployments. It comes with additional security hardening and restrictions compared to the snap security on classic desktop distributions.
Please note that the list below is not comprehensive, and does not cover all the security features available in Ubuntu Core, but it outlines some of the major differences, as well as security mechanisms in it.
There are a few important differences in how Ubuntu Core is designed:
snapcommand – applications are packaged and delivered entirely as snaps.
Ubuntu Core uses the same boot process as classic Ubuntu. However, unlike classic Ubuntu, all applications on Ubuntu Core run under an application sandbox, and they are not permitted to modify the firmware, bootloader, kernel, modules, initrd, and init, and they are not allowed to interact with the base system except in very controlled ways.
The Ubuntu Core base system contains only the following components: kernel, the init process, snapd service, and several standard Linux/UNIX tools and libraries to make application development easier.
Ubuntu Core only exposes a very small subset of the systemd specification in the snap packaging. On system install, the systemd unit file is auto-generated based on these packaging options. This prevents snaps from interacting with systemd and the system in uncontrolled ways.
As part of provisioning, one user account is setup using the Ubuntu SSO as the name of the user. By default this user has console access disabled and SSH access allowed via the SSH key stored in Launchpad for the user. This user is in the sudo group and thus capable of running commands as root. Multi-user support is limited on Ubuntu Core, but alternate user accounts can be set up using standard tools.
As we briefly mentioned earlier, Ubuntu Core differs from classic Ubuntu in how software is distributed, including core operating system snap, pre-installed snaps and snaps installed via the store.
Application snaps are considered untrusted. We touched on this in the first article on security, whereby we mentioned that untrusted applications:
To understand how the snap packaging, security policy and runtime restrictions all work together, let’s examine a use case. Below, we have a sample
snapcraft.yaml file for a foo application. This content will be transformed into a snap and uploaded to the store. In this example, the snap is assigned revision 7 by the store.
description: foo does stuff
What do we have here? We have a snap named foo, version 1.0. It has two commands in it, one called bar and one called ctl. Bar is a background service (daemon), and it requests access to qux and network interfaces. Ctl runs the bin/control executable.To make the example more complete, there is also an existing snap named baz.
The snap named baz has an application named norf. It is a D-BUS message bus type background service, and it provides a slot named qux, to snaps that request access (plug) for qux.
When foo runs, the following happens:
Snap security comprises several layers, and users often only see the top one, working and interacting with snaps. But there is a lot happening under the surface, starting with robust operating system fundamentals, and continuing with hardening policies and a strong trust model. Hopefully, this article has shed some light of the things happening behind the scenes, which should give you a better understanding and more confidence into the snap security model.
Furthermore, Ubuntu Core introduces additional measures, specifically tailored for IoT devices. With the entire system deployed as snaps, and further restrictions on what snaps can do, Ubuntu Core is a dependable choice for IoT deployments.If you have any thoughts or feedback on this article, we invite you join our discussion forum.
Learn how the Ubuntu desktop operating system powers millions of PCs and laptops around the world.
Snapcraft squad Report a Snap Last year, a snap was found in the Snap Store using computing resources for bitcoin mining without user consent. This software was retired from the Store after further investigation and highlighted the need…
With a proliferation of related hardware, software and solutions being rushed out to capture the promise of a multi-billion dollar IoT industry, vendors are under pressure to decrease their development time and speed up their time to…
My current job involves me mostly working in the upper layers of the desktop software stack however I started out working in what was then called embedded engineering but now would probably be know as the Internet of Things (IoT). I worked…