EUD Security Guidance: Ubuntu 16.04 LTS

This guidance was developed following testing on laptops running Ubuntu 16.04.1 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 of recommendations and should not be seen as a set of mandatory instructions 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 16.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. 

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 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, the tpm-luks project can enable usage of Trusted Platform Modules (TPMs) by LUKS which may help meet more of these requirements.
Secure boot	Secure boot is not fully supported on this platform. 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 an opportunity for a local attacker to exfiltrate keys and data.

 

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 Foundation Grade IPsec VPN client configured as per that product’s security procedures to provide data-in-transit protection.
Data at rest	Use LUKS/dm-crypt to provide full volume encryption.
Authentication	The user has a different authentication 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	At present, Ubuntu cannot be configured to fully boot securely. Minor security benefit can be obtained by applying the configuration given in the Recommended Policies and Settings section 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.
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 by your in-house scanning capabilities.
Security policy enforcement	The enforcement of security policies will be conducted by various operating system components and third-party products, based upon configuration files contained in specific directories. These include Policy Kit rules and LightDM settings, DConfsettings, PackageKit rules, gksu settings and gksudo settings. These configuration changes can be managed centrally through the use of Ubuntu packages, which can be deployed from the Software Configuration Management server. Settings applied by the administrator cannot be modified by the user.
External interface protection	Interfaces can be configured using standard platform configuration files. DMA is possible from some external interfaces including FireWire and Thunderbolt. As this platform does not control access via DMA it is advisable to procure hardware which does not have external DMA interfaces present if possible.
Device updates	Operating system security updates can be configured to be automatically applied. Using the recommended automatic setting, application updates are installed automatically when the device is switched on and fully booted. Kernel updates are applied when the user restarts their Ubuntu device.
Event collection	By default, the majority of applications on Ubuntu will use RSyslog to output event logs. RSyslog can forward logs to a remote server which is most reliable when using TCP or the RELP protocol and can be secured with TLS encryption. RSyslog can also be configured to queue log messages when the remote server is unavailable and flush this queue to disk when the system is shutdown. This can avoid messages being discarded when connectivity to the central log server is unavailable. Additional auditing can also be performed with auditd for specific events of interest to an administrator.
Incident response	There is no native remote wipe functionality available for Ubuntu, but remote wipe functionality can be implemented with a configuration management system such as Puppet. This system could also destroy key material for encrypted hard drives or use a secure erase feature of the drive if present. Access to the enterprise network can be prevented by revoking the VPN client certificate associated with a lost or stolen device. Additionally, the client certificates for any other enterprise servers (such as email) that are stored on the device should be revoked.

Recommended network architecture

All remote or mobile working scenarios should use a typical remote access architecture with a VPN terminating into an access layer (or DMZ). The following network diagram describes this set up. 

Preparation for deployment 

It is possible to deploy Ubuntu with the recommended configuration either via a Software Configuration Management (SCM) service or to deploy this configuration with the install and post-install scripts provided with this guidance. An SCM service can help manage a large number of machines with differing requirements from a central location, although deploying with a script at install time can be simpler for smaller scale deployments.

If using a Software Configuration Management (SCM) service, the following steps should be taken:

1. Procure and provision an SCM server, such as Puppet or Chef. Optionally, install Landscape as the system management tool.
2. Produce and provision an Ubuntu repository mirror and custom repository. This can be installed on the same host as the Software Configuration Management server.
3. Install and configure Ubuntu 16.04.1 LTS x86_64 on a dedicated system for the purpose of building configuration packages.
4. Create signed packages to push the security configuration settings, and upload them to the custom repository. Update the list of packages in the Software Configuration Manager by re-synchronising with the repositories if required.

Device provisioning steps

1. With the device configured to use UEFI mode, with no support for Legacy booting, and Secure Boot enabled, the device should be booted to the latest x86_64 Ubuntu 16.04 LTS Desktop Live CD.
2. At the GRUB menu, the “Try Ubuntu without installing” option should be selected.
3. Once the desktop has loaded, installation can proceed with the provided installation script (which can be copied from a USB stick). This script will:

• clear any existing partitions from the disk and create a GUID Partition Table (GPT) with a 512MB EFI partition at the start of the disk followed by a 512MB Linux Native boot partition and the remaining free space as an encrypted Linux Logical Volume Manager (LVM) partition.
• format the LVM partition with Linux Unified Key Setup (LUKS) to enable disk encryption with the specified password and open it ready for use.
• initialise and create a Logical Volume Group in the LUKS encrypted volume.
• within the group, create volumes for a swap, /home and root (/) (optionally for /tmp).
• launch the Ubiquity installer, in which the volumes should be selected and associated with the proper mount points and set to be used as EXT4 partitions, with the exception of swap which should simply be specified as used for swap space. The boot partition should also be selected to mount as /boot and also be EXT4. After the installer, “Continue Testing” should be selected to allow the script to finish its tasks.
• create a valid /etc/crypttab in the newly installed system (achieved by mounting the relevant partitions).
• with the new system mounted and in a chroot environment execute # update-initramfs -u -k all to allow LUKS to operate correctly at boot.

1. If opting not to use an SCM service, the script will apply as much of the recommended configuration as possible at install time. The final steps can be applied with the post-install script. If using an SCM, the new system can be added to it now and the relevant configuration packages applied.
2. Create a VPN certificate for the device, along with a certificate for the intended user and copy both of these to the device over a secure network connection.
3. Configure StrongSwan to connect to the VPN gateway using the relevant profile and certificate files, and then restart the StrongSwan daemon. Example StrongSwan configuration files are provided with this guidance but these will usually need to be customised for the specific environment.

 

Recommended policies and settings

This section details important security policy settings which are recommended for an Ubuntu deployment. Other settings (e.g. server address) should be chosen according to the relevant network configuration.

Remember, any guidance points given here are recommendations – they are not mandatory. Risk owners and administrators should agree a configuration which balances business requirements, usability and the security of the platform. 

Authentication policy

Your organisation should have a consistent authentication policy which applies to all users and devices capable of accessing its data. You can use the published password guidance to help inform any password policy. An administrator should configure the relevant on-device settings in line with your authentication policy. 

For further guidance on defining an authentication policy, see the EUD Security Guidance introduction.

The password requirements in Ubuntu Desktop are controlled under the Pluggable Authentication Module (PAM) module. Configuration can be deployed in the /etc/pam.d/common-password file. To enforce the authentication policy on Ubuntu devices, the following settings are available, and should be set according to the policy:

• Minimum password complexity requirements
• Minimum password length
• Maximum number of failed attempts
• Minimum number of different characters with the previous password

Details of how to configure these can be found in the man pages for pam_unix (8), pam.d and pam.conf.

In addition, you can also configure:

• Maximum screen lock timeout (idle delay) and Enable lock on screen off (screensaver lock enabled) in either the system settings from the UI or by using the gsettings API for Gnome in the console. 
• Use of PAM modules such as pam_cracklib to perform basic checks on the new passwords.

Secure boot

Whilst Secure Boot hardware can verify the first step of the boot chain, Ubuntu does not continue verifying the booting system, so enabling and configuring Secure Boot offers no additional security benefit. 

Automatic updates

Automatic updates should be enabled by executing # dpkg-reconfigure unattended-upgrades and selecting “Yes”. Alternatively, the/etc/apt/apt.conf.d/20auto-upgrades file can be created with the following content:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";

The default configuration will only permit security-related updates to be automatically installed. This can be changed by editing the /etc/apt/apt.conf.d/50unattended-upgrades file to enable additional sources for automatic updates.

To enable additional non-security automatic updates, uncomment the line “${distro_id}:${distro_codename}-updates“;. The Unattended-Upgrade::Allowed-Origins should then contain the -security and -updates origins. Note that -security updates are also added to the -updates archive shortly after release in -security.

Other configuration settings are available and are detailed in /etc/cron.daily/apt and /etc/apt/apt.conf.d/50unattended-upgrades.

Software restriction

A separate partition should be created for /home and this, along with /run/shm and a tmpfs /tmp directory, should be configured in /etc/fstab to not allow execution of any files they contain. Users should only be able to create and edit files on these partitions. For example, this could be achieved by adding /home noexec,nosuid,nodev 0 0, none /tmp tmpfs noexec,nosuid,nodev 0 0 and none /run/shm tmpfs rw,noexec,nosuid,nodev 0 0 to /etc/fstab

Any additional locations on the file system that the non-administrator user can both write to and execute from should be identified and locked down by changing group membership or directory permissions where possible.

Known problematic locations on a 16.04.1 LTS install configured as per this guidance are /var/crash, /var/metrics, /var/tmp and /var/lib/lightdm-data. All but the latter can be addressed by removing the “other” write permission. The lightdm-data subdirectory however is manipulated by a root level LightDM process to always be writable and executable by the user, so instead create a symlink from the lightdm-data directory to a lightdm-data directory on the /home partition (which is mounted with noexec) as in the example below:

# mkdir /home/lightdm-data
# chmod 755 /home/lightdm-data
# ln -s /home/lightdm-data /var/lib/lightdm-data

According to the Filesystem Hierarchy Standard (FHS), the /tmp and the /var/tmp directories are used to store temporary files. However, the /var/tmpdirectory offers persistence between system reboots. In deployments where persistence in /var/tmp is not required, an option could be to bind the /var/tmpfolder to the /tmp folder. This will allow the /var/tmp directory to inherit the same mount settings as the /tmp directory during the system startup, hence securing the /var/tmp directory in the same manner /tmp is protected. This could be achieved by adding /tmp /var/tmp bind 0 0 to /etc/fstab.   

Remaining locations, if any, should be added to the deny rules in the AppArmor configuration as shown below. The command # find / -type d -writable will identify directories where a user can write files when run as that user. Locations on partitions where execution is not possible can be ignored.

Install additional AppArmor profiles and set ones for software that is installed into enforce mode. The extra profiles can be obtained by executing # apt-get update followed by # apt-get install apparmor-profiles apparmor-utils. Then execute the following to put specific profiles for software that is installed in the recommended configuration into enforce mode:

# aa-enforce /etc/apparmor.d/usr.bin.firefox
# aa-enforce /etc/apparmor.d/usr.sbin.avahi-daemon
# aa-enforce /etc/apparmor.d/usr.sbin.dnsmasq
# aa-enforce /etc/apparmor.d/bin.ping
# aa-enforce /etc/apparmor.d/usr.sbin.rsyslogd

Also note that ensuring the end user’s account does not have sudo access is also important to ensure proper software restriction. More details on this can be found in the User Setup section below.

If shell access is not required it can be disabled. To do this, before creating any users, set the default shell to /usr/sbin/nologin in both /etc/default/useradd and /etc/adduser.conf. This prevents users gaining access to the shell via the console, SSH, or the GUI.

User setup

1. The default Ubuntu installer, Ubiquity, will create a user account during install. For the recommended configuration this user account should be considered to be the administrator of the system and not be assigned to the end user of the device. This user account will have sudo access with which it can perform administration tasks. After install, another user account should be created with adduser with default options. This user account should not have sudo access and the password can be provided to the end user of the device. As a further step, this user account can be prevented from executing the su command by running # dpkg-statoverride --update --add root adm 4750 /bin/su to change the commands permissions. Similar protection can also be applied to gksu, gksudo, pkexec, pkcon and so on, as appropriate.
2. Disable guest login through LightDM by creating /etc/lightdm/lightdm.conf.d/50-no-guest.conf with the following content (leaving a blank line at the end of the file):

[SeatDefaults]
allow-guest=false

1. Remove read access to user home directories and set a more secure default umask:

• For any existing home directories, use chmod 750.
• In /etc/adduser.conf ensure the DIR_MODE1 setting is set to 0750.
• In /etc/login.defs ensure the line UMASK setting is set to 027.

Privacy

By default Ubuntu has some features enabled which can be a privacy concern. To disable these features take the following step:

1. Disable Apport error reporting by ensuring that /etc/default/apport contains enabled=0.

These settings should be locked so users cannot unset them by doing the following steps:

• Create a /etc/dconf/profile/user file containing:

user-db:user
system-db:local

• Create a /etc/dconf/db/local.d/unity file containing:

[com/canonical/unity/lenses]
remote-content-search=false

• Create a /etc/dconf/db/local.d/locks/unity file containing:

# Do not allow remote content searching in Unity
/com/canonical/unity/lenses/remote-content-search

Then run # dconf update.

VPN

Use a Foundation Grade IPsec VPN client to provide data-in-transit protection.

Recommended PSN IPsec profile configuration summary:

PSN end-state IPsec profile

ESP
Encryption	AES-128 in GCM-128
IKEv2
Encryption	AES-128 in GCM-128 (and optionally CBC*)
Pseudo-random function	HMAC-SHA256-128
Diffie-Hellman group	256-bit random ECP (RFC5903), Group 19
Authentication	ECDSA-256 with SHA-256 on P-256 curve

* If supporting CBC for IKEv2 encryption, the integrity algorithm that should be used is HMAC-SHA256-128.

A sample strongSwan default section for the above is:

conn %default keyexchange=ikev2 ike=aes128gcm128-prfsha256-ecp256! esp=aes128gcm128-ecp256! ikelifetime=24h lifetime=20m margintime=3m keyingtries=%forever closeaction=restart dpdaction=restart

Firewall

The firewall should be configured to block incoming connections. External connections can also be limited to only allow access to provisioned enterprise services. You can do this using a ufw configuration such as:

# ufw limit 22/tcp # Limit incoming SSH connections to 6 connections per IP address per 30 seconds
# ufw enable

Restrict outgoing access solely to the VPN server (172.99.99.2 in this example):

# ufw allow out proto udp to 172.99.99.2 port 500
# ufw allow out proto udp to 172.99.99.2 port 4500
# ufw default deny outgoing

Normal traffic will be able to flow down the IPsec tunnel once the security association is established (leftfirewall=yes must be set in the StrongSwan configuration file).

In order for DHCP on the LAN to function, this must be allowed:

# ufw allow out from any port 67 to any port 68 proto udp
# ufw allow out from any port 68 to any port 67 proto udp

Alternatively for more fine-grained configurations, the iptables-persistent package may be used:

# apt-get install -y iptables-persistent

Other considerations

The following points are in addition to the common organisational considerations, and contain specific issues for Ubuntu deployments.

Application whitelisting

Ubuntu can be configured such that users cannot run programs from areas where they are permitted to write files. This ensures users can only access programs provisioned by an administrator, although this also prevents users from installing pre-approved software by themselves.

In addition, it is recommended that users do not have access to script interpreters such as Python, Perl, or shells including bash. Access to these can be restricted using a combination of AppArmor, file permissions, and file attributes.

Auditing

Auditing can be enabled and configured via an application called auditd. Rules can be configured which enable auditing of various system events.

This can be installed with the following command:

# apt-get install -y auditd

Additional configuration is required in order for auditd to monitor for events. The following examples can be used.

Monitoring changes and execution within /tmp

In /etc/audit/rules.d/tmp-monitor.rules, place the following configuration:

# Monitor changes and executions within /tmp
-w /tmp/ -p wa -k tmp_write
-w /tmp/ -p x -k tmp_exec

Monitoring administrator access to /home directories

In /etc/audit/rules.d/admin-home-watch.rules, place the following configuration:

# Monitor administrator access to /home directories
-a always,exit -F dir=/home/ -F uid=0 -C auid!=obj_uid -k admin_user_home

If files are created or modified within /etc/audit/rules.d/ then # augenrules must be run to merge the changes to the main auditd configuration. Once run, restart auditd with service auditd restart

Audit events are then recorded in /var/log/audit/audit.log. This file can be parsed with various tools, such as aureport. Example usage of this command is # aureport --input /var/log/audit/audit.log

To test the above configuration, the following commands will trigger the auditing rules:

$ touch /tmp/audit_test_file
$ chmod u+x /tmp/audit_test_file
$ /tmp/audit_test_file
$ sudo -i
# ls /home

Snap Packages and Security Considerations

Ubuntu 16.04 LTS introduced a new application package format, the ‘snap’, which can be installed alongside traditional DEB packages. The two packaging formats can co-exist in the same environment, however they differ on the way they are installed, executed and updated.

The ‘snap’ packages are self-contained application binaries and they include any dependencies needed to run. A ‘snap’ package will install to its own directory and it will run in application confinement, hence access to the system resources is restricted based on snap-specific security policies such as AppArmor profiles and seccomp filters. Authorised ‘snap’ packages are available through the Ubuntu Store. When a snap is uploaded on the Ubuntu Store, it undergoes automatic reviews, which involve examining the ‘snap’ package’s requested interfaces by reviewing the associated security policy. Auditing is also configured for the installed application to ensure logging of unauthorised operations.

In order to ensure that the installation of ‘snap’ packages does not introduce any risk to the security posture of your system, it is recommended that ‘snap’ packages are only installed from the authorised Ubuntu Store and from trusted developers.

An additional security concern arises from the fact that the ‘snap’ packages can bundle their own versions of system libraries, so they will not depend on the installation of other packages or libraries. In the event that a vulnerability in a system library is discovered, any ‘snap’ packages that include the affected system library as a dependency will be vulnerable until the ‘snap’ package’s developers push a secure version of the package. In traditional deployments i.e. using DEB packages, this would have been resolved when the distribution sent out security updates addressing the vulnerable system library.

It is advised that any installed ‘snap’ packages are updated in a timely manner to their latest, secure version available on the Ubuntu Store.

Source: NCSC