Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise Server 12 SP3

1 Overview and rationale

1.1 What is the Common Criteria Certification?

Common Criteria is the best known and most widely used methodology to evaluate and measure the security value of an IT product. The methodology aims to be independent, as an independent laboratory conducts the evaluation, which a certification body will certify afterward. Security Functional Requirements (SFR) are summarized in so-called Protection Profiles (PP), which allows the comparison of security functions of different products if the definition of the Security Target (ST) (which typically uses a reference to the PP if one exists that fits the purpose of the product) and the Evaluation Assurance Levels are comparable.

A clear definition of security in IT products is challenging. Security should be considered a process that never ends, not a static condition that can be met or not. A Common Criteria certificate (below EA7) does not make a clear statement about error proneness of the system (while many of the flaws that exist specifically in operating systems are security-relevant), but it adds an important value to the product that cannot be described with the presence of technology alone: That someone has independently inspected the design of the system in such way that it corresponds to the claims that are made, and that explicit care has been taken in producing and maintaining the product.

The certificate states a degree of maturity of both the product with its security functions and the processes of the company that has designed, built and engineered the product, and that will maintain the product across its life cycle. As such, Common Criteria aims to be fairly holistic with its approach to take everything into account that is relevant for the security of an IT product.

The Evaluation Assurance Level (EAL) shall denote the degree of confidence that the product fulfills the described claims. The levels are from 1 through 7:

  • EAL1: Functionally tested

  • EAL2: Structurally tested

  • EAL3: Methodically tested and checked

  • EAL4: Methodically designed, tested and reviewed

  • EAL5: Semi-formally designed and tested

  • EAL6: Semi-formally verified design and tested

  • EAL7: Formally verified design and tested

While EAL1 only provides basic assurance for products to meet security requirements, EAL2 to 4 are medium assurance levels. EAL5-EAL7 describe medium-to-high and high assurance; EAL4 is expected to be the highest level of assurance that a product can have if it has not been designed from the start to achieve a higher level of assurance.

Many commonly known General Purpose/Utility Computing operating systems have been awarded a Common Criteria certificate at EAL4. A "+" after the assurance level denotes an augmentation to the EAL, an addition that is useful for the articulation of security value, but formally not needed at the corresponding EAL.

The SUSE Linux Enterprise Server version 8 was the first Linux system to achieve EAL3+ (Augmentation: Basic Flaw Remediation) in 2003; Version 9 of SLES was the first Linux based operating system to reach EAL4+ in 2004. More certifications and re-certifications have followed targeting SLES 9 and SLES 10-SP1, until the SUSE Linux Enterprise Server version Service Pack 2 was evaluated in 2011/2012.

The Common Criteria evaluations inspect a specific configuration of the product in an evaluated setup. The Administrator's Guide is a document that comes with a Common Criteria certified product and describes the individual steps that need to be taken to install and configure the product to a state like it was evaluated.

Very often, the evaluated configuration is used as a reference for the secure installation of the SUSE Linux Enterprise Server. It is however incorrect to understand the evaluated configuration as a hardened configuration: the removal of setuid bits and the prescription of administrative procedures after installation is there to reach a specific configuration that is sane, but this process is clearly insufficient for a hardening claim.

Earlier versions of this document have contained a substantial part that links to Common Criteria evaluated configurations. For clarity and to avoid confusion these chapters have been removed.

Instead, this guide recommends the lecture the documentation that comes with the Common Criteria certificate to understand the Common Criteria evaluation of SUSE Linux Enterprise Server in general, the security functions that are in place within the operating system and how these security functions are relevant for the mitigation of threats. The High Level Design documentation encompasses the design specifics of the SUSE Linux Enterprise Server: Authentication mechanisms, access controls, audit subsystem and system log files, to name a few of them. The accumulated knowledge contained in the documentation allows decision making for hardening purposes at an informed level—find it at http://www.suse.com/security/.

Apart from the valuable documentation that comes with the Common Criteria effort, the following manual pages may be of greater interest to the inclined reader:

pam(8), pam(5)

apparmor(7) and referred man pages

rsyslogd(8), syslog(8), syslogd(8)

fstab(5), mount(8), losetup(8), cryptsetup(8)

haveged(8), random(4)

ssh(1), sshd(8), ssh_config(5), sshd_config(5), ssh-agent(1), ssh-add(1), ssh-keygen(1)

cron(1), crontab(5), at(1), atd(8)

systemctl(1), daemon(7), systemd.unit(5), systemd.special(5), kernel-command-line(7), bootup(7), systemd.directives

1.2 Generic Guiding Principles

The following guiding principles motivate much of the advice in this guide, and security processes in general, and should also influence any configuration decisions that are not explicitly covered.

Use Data Encryption Whenever Possible

Refer to the About This Guide section of this guide. In Section 1, “Assumptions and Scope”, the limitations of cryptography are briefly outlined.

Be aware that cryptography is certainly useful, but only for the specific purposes that it is good for. It is not a generic recipe for better security in a system, its use may even impose additional risk on the system. Make informed decisions about the use of cryptography, and feel obliged to have a reason for your decisions, no matter if they are for or against cryptography. A false sense of security can be more harmful than the weakness itself. SUSE Linux Enterprise Server supports encryption for generic network connections (the openssl command, stunnel), for remote login (openssh, man ssh(1)), for generic file encryption (gpg), for entire file systems at block layer (dm_crypt, cryptsetup) and for VPN (iipsec, openvpn).

Minimal Package Installation

Generally, an RPM software package consists of the package's meta data that is written to the RPM database upon installation, the package's files and directories and scripts that are being executed before and after installation and removal.

If the package does NOT contain

  1. setuid- or setgid bits on any of the installed files

  2. group- or world-writable files or directories

  3. a service that is activated upon installation/activated by default.

then the said package generally does not impose any security risk to the system. Under the above condition, the package is merely a collection of files, and their use shall not be automatically assumed if you do not have any local users on your system. Since the installation of such packages does not have any influence on the security value of the system, the uninstallation of them should not either.

However, a fairly simple reason to keep to a minimal set of packages in your installation is that something that is not present cannot get used. Binaries not installed cannot be executed.

A straight forward way of keeping to a minimal set of packages begins with the installation of the system. You can start the installation of your system by deselecting all packages and then select only those that you want to use. As an example, the selection of the apache2-mod_perl package in YaST would automatically cause all packages to be selected for installation that are needed for the Apache package to operate. Dependencies have often been artificially cut down to be able to handle the system's dependency tree more flexibly. You should be safe if you chose the minimal system, and build the dependency tree from there with your (leaf) package selection.

Service Isolation—Run Different Services on Separate Systems

Whenever possible, a server should be dedicated to serving exactly one service or application. This limits the number of other services that could be compromised in the event an attacker can successfully exploit a software flaw in one service (assuming that flaw allows access to others).

This point can lead to healthy and robust dialog on system sizing and even further to consolidation or virtualization. The intent with this guidance is to reduce the fault domain and risk where possible.

The use of AppArmor for services that are provided on a system is an effective means of containment. Refer to the AppArmor documentation on your system to learn more. man apparmor is a good starting point.

The use of virtualization technology with KVM or with Xen is supported with the SUSE Linux Enterprise Server version 12 SP3. While virtualization is generally designed for server consolidation purposes, its usefulness for service isolation is another good argument. Be aware that the capability of the hypervisor to separate virtual machines is not higher or stronger than the Linux kernel's capability to separate processes and their address spaces. The granularity at which virtualization technology tackles separation may however come with its benefits, being resource-hungry and somewhat clumsy on the other hand.

Note
Note

Virtualization technology cannot match or substitute the separation strength that is given by running services on different physical machines!

System fingerprinting and backups

In the case of the suspicion of an attack against the system, nothing can provide more comfort than

  1. a backup

  2. a fingerprint of your system to detect modifications

  3. having done your homework.

Several tools exist on SUSE Linux Enterprise Server 12 SP3 which can be effectively used for the detection of unknown, but yet successful attacks. These tools come at the cost of relatively little configuration effort, but with the benefit of being able to actually know what has been changed in your system.

In particular, the use of AIDE is strongly encouraged. AIDE, when run for initialization, creates a hash database of all files in the system that are listed in its configuration file. This allows to verify the integrity of all cataloged files at a later time.

Note
Note

You need to copy the hash database that AIDE creates to a place that is inaccessible for potential attackers. Otherwise, the attacker may modify the integrity database after planting a backdoor, thereby defeating the purpose of the integrity measurement.

Note
Note

An attacker may have planted a backdoor in the kernel. This has an entire variety of consequences: Apart from being very hard to detect, the kernel-based backdoor can effectively remove all traces of the system compromise to the degree that system alterations are almost invisible. By consequence, an integrity check needs to be done from a rescue system (or any other system where an independent system runs, and the target system's file systems are mounted manually).

Note
Note

Security is a lively process. Essentially, in this context, this means that the application of security updates invalidates the integrity database. rpm -qlv packagename lists the files that are contained in a package. Generally spoken, the RPM subsystem is very powerful with the data that it maintains, and that is accessible with the --queryformat command line option. A differential update of integrity database with the changed files becomes more manageable with some fine-grained usage of RPM.

A fast and directly accessible backup adds distinct confidence about the integrity of your system and can substitute an integrity check such as described above with AIDE. It is important, though, that the backup mechanism/solution has adequate versioning support so that you can trace changes in the system. As an example: The installation times of packages (rpm -q --queryformat='%{INSTALLTIME} %{NAME}\n' PACKAGE NAME) must correspond to the changed files in the backup log files.

Note
Note

Make it an integral part of your security routine to verify that your backups work.

Print this page