SYS.2.3 Linux and Unix Clients

Administrators MUST NOT log in as “root” during normal operations. For system administration tasks, “sudo” or an appropriate alternative with appropriate logging SHOULD be used. Multiple users SHOULD be prevented from logging into a client simultaneously.

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

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

If software requiring installation is to be compiled from source code, the software MUST ONLY be unpacked, configured, and compiled using an unprivileged user account. The software to be installed MUST NOT then be installed in the root file system of the operating system in question in an uncontrolled manner.

If the software is compiled from source text, the selected parameters SHOULD be documented appropriately. Based on this documentation, it SHOULD be possible to compile the software in a transparent and reproducible manner at any time. All further installation steps SHOULD also be documented so that the configuration can be reproduced quickly in emergencies.

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

It SHOULD be ensured that services and applications are only allowed to create, change, or delete the files assigned to them. In directories in which all users have write privileges (e.g. /tmp), the sticky bit SHOULD be set.

In order to restrict the access rights of applications to files, devices, and networks, AppArmor or SELinux SHOULD be used. The solutions with the best protection provided by the respective Unix derivative or Linux distribution SHOULD be selected. The necessary applications SHOULD be regulated through whitelisting instead of blacklisting. Extensions regarding the restriction of rights SHOULD be used in enforcing mode or by means of appropriate alternatives.

Passwords SHOULD NOT be transferred to programs as parameters.

Quotas for users or services SHOULD be set that leave enough capacity for the operating system. In general, different partitions SHOULD be used for the operating system and data. Alternatively, mechanisms of the file system in use SHOULD also be used that only grant write privileges to the “root” user once an appropriate level of capacity has been reached.

It SHOULD be ensured that appliances are characterised by a level of security similar to that of clients on standard IT systems. It SHOULD be documented how the corresponding security requirements are met when using an appliance. If it is not possible to unequivocally comply with the requirements, a declaration of conformity SHOULD be requested from the respective manufacturer.

It SHOULD only be possible to use peripheral devices if they are included in a centrally managed whitelist. Kernel modules for peripheral devices SHOULD only be loaded and enabled if the devices can be found on the applicable whitelist.

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

The use of system calls SHOULD be restricted to the necessary minimum (e.g. by means of “seccomp”), particularly for exposed services and applications. The existing standard profiles and rules of SELinux and AppArmor, as well as of alternative extensions, SHOULD be checked manually and adapted as required to the security policy at hand. If necessary, new rules and profiles SHOULD be drawn up.

Appropriate protective safeguards such as memory protection, file system protection, and role-based access control SHOULD be implemented with specially hardened kernels (e.g. grsecurity, PaX) to prevent exploitation of vulnerabilities and propagation in operating systems.

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

The SysRq functions that users may execute SHOULD be specified. In general, it SHOULD NOT be possible for users to trigger any critical SysRq functions.