Ubuntu Security Guidance by GCHQ

This guidance was developed following testing on devices running Ubuntu 18.04 LTS.

It's important to remember that this guidance has been conceived as a way to satisfy the 12 End User Device Security Principles . As such, it consists ofrecommendationsandshould notbe seen as a set of mandatoryinstructions requiring no further thought.

Risk owners and administrators should agree a configuration which balances business requirements, usability and security.

Risk owners' summary

We recommend the following architectural choices for Ubuntu 18.04 LTS :

All data should be routed over a secure enterprise VPN to ensure the confidentiality and integrity of the traffic, and to benefit from enterprise protective monitoring solutions. Users should not be allowed to install arbitrary applications on the device. Applications should be authorised by an administrator and deployed via a trusted mechanism. Most users should have accounts with no administrative privileges. Users that require administrative privileges should use a separate unprivileged account for email and web browsing. It is recommended that local administrator accounts have a unique strong password per device.

When configured in this way, risk owners should be aware of the following technical risks associated with this platform:

Associated security principle Explanation of risks

Data in transit

Users may choose to ignore certificate warnings leaving data in transit vulnerable to interception and alteration.

Data at rest

The linux Unified Key Setup (LUKS)/dm-crypt disk encryption solutions have not been independently assured to Foundation Grade, and do not support some of the mandatory requirements expected from assured full disk encryption products . Without assurance there is a risk that data stored on the device could be compromised. However, thetpm-luksproject can enable usage of Trusted Platform Modules (TPMs) by LUKS which may help meet more of these requirements.

Secure boot

Secure boot validates the bootloader, kernel and kernel modules. However, some boot-related files are not protected by default and could be modified by an attacker to tamper with the boot process. Hardening of the boot process can help mitigate the risk.

Ubuntu does not use any dedicated hardware to protect its disk encryption keys. If an attacker can get physical access to the device, they can perform an offline brute-force attack to recover the encryption password.

Encryption keys protecting sensitive data remain available to an attacker when the device is locked. This means that if the device is attacked while powered on and locked, keys and data on the device may be compromised without the attacker knowing the password.

External interface protection

Whilst not specific to Ubuntu itself, many devices which can run Ubuntu have external interfaces which permit Direct Memory Access (DMA) from connected peripherals. This presents a local attacker with an opportunity to exfiltrate keys and data.

Software configuration of the FireWire and Thunderbolt interfaces can reduce the risk for these interfaces.As of 18.04.1 this can be managed through the settings UI.

Administrators' deployment guide Overview

To meet the principles outlined in the End User Devices Security Framework , several recommendations are given in the table below.

Security Principle Explanation

Data in transit

Use a Prime or Foundation Grade IPsec VPN client configured as per that product’s security procedures to give data-in-transit protection.

Data at rest

Use LUKS/dm-crypt to provide full volume encryption.

Authentication

The user has a different password to authenticate themselves to the device once they have entered the decryption password.

Alternatively, the user can implicitly authenticate to the device by decrypting the disk at boot time with their LUKS/dm-crypt password. This password unlocks a key which encrypts certificates and other credentials, giving access to enterprise services.

The user should be required to authenticate to the device in line with your organisation’s authentication policy (see Authentication Policy ).

Secure boot

Enable secure boot. Ubuntu validates the boot process but does not verify all boot-related files against tampering. Security benefit can be obtained by applying the configuration given in theRecommended Policies and Settingssection below, but this will not fully satisfy the secure boot recommendation.

Platform integrity and application sandboxing

These requirements are met implicitly by the platform. Where available, AppArmor profiles limit applications’ access to the platform. Other applications can be configured to use AppArmor if required. Snap applications run confined in a restricted sandbox .

Application whitelisting

Permissions can be configured at install time to ensure users cannot execute applications from any disk partition that they can write to. All application installation should be performed by an administrator.

Malicious code detection and prevention

The platform implicitly provides some protection against malicious code being able to run when configured as recommended.

Several third-party anti-malware products exist which attempt to detect malicious code for this platform. Content-based attacks can be filtered byyour in-house scanning capabilities.

Security policy enforcement

The enforcement of security policies will be conducted by various operating system compo