SYS.1.3 Linux and Unix Servers

Each login name, each user ID (UID), and each group ID (GID) MUST ONLY be used once. Every user MUST be a member of at least one group. Every GID mentioned in the /etc/passwd file MUST be defined in the /etc/group file. Every group SHOULD only contain the users that are absolutely necessary. In networked systems, care MUST also be taken to ensure that user and group names (UIDs and GIDs) are assigned consistently in the system network if there is a possibility that the same UIDs or GIDs could be assigned to different user or group names on the systems during cross-system access.

Removable media such as USB pen drives or CDs/DVDs MUST NOT be integrated automatically.

ASLR and DEP/NX MUST be activated in the kernel and used by applications to make it harder to exploit vulnerabilities in applications. Security functions of the kernel and of the standard libraries (such as heap and stack protection) MUST NOT be disabled.

If software to be installed is to be compiled from source code, it 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 server in question in an uncontrolled manner.

If the software is compiled from the 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.

The corresponding management tools SHOULD be used for managing users and groups. The configuration files /etc/passwd, /etc/shadow, /etc/group, and /etc/sudoers SHOULD NOT be edited directly.

Only Secure Shell (SSH) SHOULD be used to create an encrypted and authenticated interactive connection between two IT systems. All other protocols whose functions are covered by Secure Shell SHOULD be disabled completely. For authentication, users SHOULD primarily use certificates instead of passwords.

Services and applications SHOULD be protected with individual security architecture (e.g. with AppArmor or SELinux). In addition, chroot environments and LXC or Docker containers SHOULD be taken into account here. It SHOULD be ensured that the standard profiles and rules provided are activated.

Information output for users regarding the operating system and access to protocol and configuration files SHOULD be limited to the required minimum. Moreover, confidential information SHOULD NOT be provided as parameters when commands are issued.

The use of system calls SHOULD be limited to those absolutely necessary, particularly for exposed services and applications. The standard profiles and/or rules (e.g. of SELinux or AppArmor) SHOULD be checked manually and, if necessary, adapted to an organisation's own security policies. If necessary, new rules and profiles SHOULD be drawn up.

Specially hardened kernels (e.g. grsecurity, PaX) and appropriate protective safeguards such as memory protection or file system protection SHOULD be implemented to prevent exploitation of vulnerabilities and propagation in operating systems.