SYS.2.3 Clients Running Linux and Unix

Description

Introduction

In addition to Windows, Linux or less commonly Unix-based operating systems are being installed on an increasing number of clients. Examples of classic Unix systems include the BSD family (FreeBSD, OpenBSD, and NetBSD), Solaris, and AIX. Linux, in contrast, is not a classic Unix but a functional Unix system, as the Linux kernel is not based on the original source code from which the various Unix derivatives developed. Since the configuration and operation of Linux and Unix clients are similar, this building block collectively refers to Linux and Unix as “Unix clients” or “Unix-like.”

Linux is free software developed by the open-source community. This means it may be used, copied, distributed, and modified by anyone. In addition, there are companies that bundle and maintain the Linux kernel and the various software components into a distribution and offer additional services. Derivatives of the Debian, Fedora / Red Hat Enterprise Linux, or openSUSE / SUSE Linux Enterprise distributions are commonly used. In addition, there are Linux distributions tailored for specific use cases and devices. These include, for example, Qubes OS, which attempts to achieve a high level of security through virtualization; LibreElec for use as a Home Theater PC (HTPC); and Kali Linux, a distribution specialized in security, computer forensics, and penetration testing. Clients can also boot live distributions without changing the operating system installed on the client. The market share of the Linux operating system on clients has increased in recent years. In specialized deployment environments, “classic” Unix systems in various derivatives continue to be used. Typically, such an IT system is networked and operated as a client in a client-server network.

The large number of pre-selected software packages in a standard installation of common Linux distributions or Unix derivatives, on the one hand, increases the attack surface. At the same time, however, Unix-like operating systems also offer extensive protective mechanisms.

Objective

The objective of this building block is to protect information that is created, edited, stored, or sent on Linux and Unix clients. The requirements of the building block apply primarily to Linux clients but can generally be adapted for Unix clients.

Scope and Modeling

The building block SYS.2.3 Clients Running Linux and Unix is to be applied to all clients on which Linux or Unix-based operating systems are used.

This building block contains fundamental requirements for operating Unix-like clients. It specifies and supplements the aspects covered in building block SYS.2.1 General Client with the specific characteristics of Unix systems. Accordingly, both building blocks must always be applied together.

Even though Apple’s macOS is a Unix-like operating system, it is not addressed in this building block. Recommendations for macOS can be found in building block SYS.2.4 Clients Running macOS.

The building block covers only the operating system itself, which is generally installed during a base installation of a distribution. Software built on top of it — such as email clients or office software — is not addressed in this building block. Requirements for these can be found, for example, in the building blocks of the APP.1 Client Applications layer of the IT-Grundschutz Compendium.

This client building block assumes that, in addition to administrators, only a single unchanged person with an interactive account is permanently active. Clients used by multiple persons sequentially or simultaneously require additional measures not addressed in the scope of this building block.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to describe the threat landscape. The following specific threats and vulnerabilities are of particular significance for building block SYS.2.3 Clients Running Linux and Unix.

Software from Third-Party Sources

On Unix-like IT systems, users sometimes download and compile software source code themselves rather than installing ready-made software packages. When ready-made software packages are used, they are also in some cases installed from third-party sources without further review, rather than exclusively from the package sources of the producing company. Each of these alternative approaches to software installation carries additional risks, as they can result in the installation of faulty or incompatible software, or malicious software.

Exploitability of the Scripting Environment

Script languages are often used in Unix-like operating systems. Scripts are a listing of individual commands stored in a text file and called, for example, from the command line. Due to the extensive range of functions in the scripting environment, attackers can extensively exploit scripts for their own purposes. Furthermore, activated scripting languages can be very difficult to contain.

Dynamic Loading of Shared Libraries

The command line option LD_PRELOAD causes a dynamic library to be loaded before all other standard libraries required in an application. This allows individual functions of the standard libraries to be selectively overridden by custom ones. Attackers could, for example, manipulate the operating system such that malicious functions are also executed when certain applications are used.

Misconfiguration

Even in a standard installation of Unix-like operating systems, numerous applications are installed that must each be configured separately. Applications that are subsequently installed must also be configured separately, so that a large number of configuration files eventually exist on the operating system.

Since many applications are configured independently of one another, configuration options may conflict with each other without this being apparent from the individual settings. For example, a service for remote administration might be listening on a port that is blocked by packet filter rules. In this way, applications can provide additional functions that are not desired, or may not offer important functions. This can result in certain tasks at the client being made more difficult or not possible at all.

Requirements

The following are the specific requirements of building block SYS.2.3 Clients Running Linux and Unix. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is sensible and appropriate.

Exactly one role should be Primarily responsible. In addition, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

SYS.2.3.A1 Authentication of Administrators and Users (B) [Users]

Persons with administrative rights MUST NOT log in as “root” during normal operation. For system administration tasks, “sudo” or a suitable alternative with appropriate logging SHOULD be used. It SHOULD be prevented that multiple users can log in to a client simultaneously.

SYS.2.3.A2 Selection of a Suitable Distribution (B)

A suitable Unix derivative or Linux distribution MUST be selected based on the security requirements and intended purpose. Support MUST be available for the planned period of use of the operating system. All required application programs SHOULD be directly available as part of the distribution. They SHOULD ONLY be obtained from third-party sources in exceptional cases. Distributions in which the operating system is compiled by the user SHOULD NOT be used in production environments.

SYS.2.3.A3 DISCONTINUED (B)

This requirement has been discontinued.

SYS.2.3.A4 Kernel Updates on Unix-Like Systems (B)

The client MUST be rebooted promptly after the operating system kernel has been updated. If this is not possible, live patching of the kernel MUST be activated as an alternative.

SYS.2.3.A5 Secure Installation of Software Packages (B)

If software to be installed is to be compiled from source code, it MUST ONLY be unpacked, configured, and translated under an unprivileged account. Subsequently, the software to be installed MUST NOT be installed without control into the root file system of the operating system.

If the software is compiled from source, the selected parameters SHOULD be appropriately documented. Based on this documentation, the software SHOULD be compilable traceably and reproducibly at any time. All further installation steps SHOULD also be documented.

Standard Requirements

Together with the basic requirements, the following requirements reflect the state of the art for this building block. They SHOULD generally be fulfilled.

SYS.2.3.A6 No Automatic Mounting of Removable Drives (S) [Users]

Removable drives SHOULD NOT be mounted automatically. The mounting of removable drives SHOULD be configured such that all files are marked as non-executable (mount option “noexec”).

SYS.2.3.A7 Restrictive Assignment of Permissions for Files and Directories (S)

It SHOULD be ensured that services and applications may only create, modify, or delete the files assigned to them. The sticky bit SHOULD be set on directories in which all accounts have write permissions (e.g., “/tmp”).

SYS.2.3.A8 Use of Permission Restriction Techniques for Applications (S)

To restrict the access rights of applications to files, devices, and networks, AppArmor or SELinux SHOULD be used. The solutions best supported by the respective Unix derivative or Linux distribution SHOULD be used. Rights SHOULD be denied by default and explicitly granted via allowlists only where necessary.

Extensions for rights restriction SHOULD be used in enforcing mode or with suitable alternatives.

SYS.2.3.A9 Secure Use of Passwords on the Command Line (S) [Users]

Passwords SHOULD NOT be passed as parameters to programs.

SYS.2.3.A10 DISCONTINUED (S)

This requirement has been discontinued.

SYS.2.3.A11 Prevention of Local Hard Drive Overload (S)

Quotas SHOULD be set up for accounts and services that leave sufficient free space for the operating system. In general, separate partitions SHOULD be used for the operating system and data. Alternatively, mechanisms of the file system in use SHOULD be used that, above a suitable fill level, grant write permissions only to the “root” account.

SYS.2.3.A12 Secure Use of Appliances (S)

It SHOULD be ensured that appliances meet a similar security level to clients on standard IT systems. It SHOULD be documented how the relevant security requirements are met by an appliance in use. If the requirements cannot be met without doubt, a declaration of conformity SHOULD be requested from the manufacturer.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the protection level corresponding to the state of the art. The proposals SHOULD be considered in the case of high protection needs. The specific determination is made within the framework of an individual risk analysis.

SYS.2.3.A13 DISCONTINUED (H)

This requirement has been discontinued.

SYS.2.3.A14 Protection Against Use of Unauthorized Peripheral Devices (H)

Peripheral devices SHOULD only be usable when they have been explicitly authorized. Kernel modules for peripheral devices SHOULD only be loaded and activated when the device is authorized.

SYS.2.3.A15 Additional Protection Against Execution of Unwanted Files (H)

Partitions and directories in which users have write permissions SHOULD be mounted in such a way that no files can be executed (mount option “noexec”).

SYS.2.3.A16 DISCONTINUED (H)

This requirement has been discontinued.

SYS.2.3.A17 Additional Prevention of Propagation When Exploiting Vulnerabilities (H)

The use of system calls SHOULD be restricted — especially for exposed services and applications — to the absolutely necessary number (e.g., using seccomp). The existing standard profiles or rules of SELinux, AppArmor, and alternative extensions SHOULD be manually reviewed and, if necessary, adapted to the institution’s own security policies. If required, new rules or profiles SHOULD be created.

SYS.2.3.A18 Additional Kernel Protection (H)

Specially hardened kernels (e.g., grsecurity, PaX) and appropriate protective measures such as memory protection, file system hardening, and role-based access control SHOULD be implemented to prevent exploitation of vulnerabilities and propagation within the operating system.

SYS.2.3.A19 Hard Disk or File Encryption (H)

Hard disks or the files stored on them SHOULD be encrypted. The associated keys SHOULD NOT be stored on the IT system. AEAD (Authenticated Encryption with Associated Data) methods SHOULD be used for hard disk and file encryption. Alternatively, “dm-crypt” in combination with “dm-verity” SHOULD be used.

SYS.2.3.A20 Disabling Critical SysRq Functions (H)

It SHOULD be defined which SysRq functions may be executed by users. In general, no critical SysRq functions SHOULD be able to be triggered by users.

Additional Information

Good to Know

There is no additional information for building block SYS.2.3 Clients Running Linux and Unix.