Screened

Containers are increasingly being used to install a particular application on a system. The basis of such a container is an image that provides an appropriate run-time environment for the application. In most cases, the images are based on a specific Linux distribution and contain not only the run-time environment for the application itself, but also a lot of the dependencies, which means a large number of packages in the image. If any one package is defective, all containers created on the basis of this image are affected. Thus, it is important to check deployed images regularly for vulnerabilities and update them if necessary.

A number of tools can be used for this purpose, but they differ greatly. For example, CoreOS provides a scanner named Clair [1] that can query different data sources to obtain current vulnerability information for each Linux distribution. The tool then performs a scan of the existing containers and images to verify whether locally available data is affected by the vulnerabilities. The Docker Bench for Security [2] tool takes a somewhat different approach; it is actually just a shell script that checks the existing containers based on the recommendations of the Center for Internet Security (CIS) [3] – a kind of best practices guide for the use of containers (Figure 1).

Figure 1: Docker Bench for Security checks containers against the CIS' best practices guide.

Configuration Check with OpenSCAP

The following example is based on the OpenSCAP [4] tool, a general scanner that checks systems according to the Security Content Automation Protocol (SCAP) of the National Institute of Standards and Technology (NIST). SCAP includes various standards for describing system configurations and security management.

The OpenSCAP scanner reads XML-based description files and synchronizes them with a system's configuration. SCAP includes standards such as CVE, CCE, CPE, CVSS, OVAL, and XCCDF. In particular, the last two standards play an important role. The extensible configuration checklist description format (XCCDF) helps define guidelines for the secure configuration of IT systems.

In the form of the OpenSCAP daemon [5], the project also provides a central service so that the existing SCAP content can be used to scan multiple machines without copying the respective files to the individual systems. The oscapd-cli command, which is included in the OpenSCAP daemon package, can schedule system scans so that they do not repeatedly need to be executed manually.

OpenSCAP not only makes it easy to scan physical and virtual systems, but also containers and container images, for which the project provides the oscap-docker tool, limited to Docker containers. Fortunately, however, Atomic [6] is a very flexible application that supports other appc-compatible container formats in addition to Docker. The atomic scan command lets you specify a predefined scanner for scanning vulnerabilities. For example, the scanner could be OpenSCAP, but other scanners can also be used. The man page for atomic scan [7] shows all possible options.

The OpenSCAP scanner and the OpenSCAP daemon themselves can run in a privileged container. The Atomic tool on the host then accesses the service within the container from a D-Bus interface. The following example shows how to load and configure a Fedora image from the Docker registry using the OpenSCAP software. The Atomic tool is also used for this purpose, which carries out a configuration of the host system directly from the Dockerfile using the LABEL INSTALL method. Finally, you need to define on the host that the OpenSCAP scanner will be used and specify the name of the image in which the OpenSCAP daemon with the SCAP content is available.

# dnf install atomic
# atomic install docker.io/fedora/atomic_scan_openscap
docker run --rm --privileged -v /:/host/docker.io/fedora/atomic_scan_openscap sh /root/install.sh
[...]

If you prefer to create your own container image with OpenSCAP, you can do so using the data from the project's Git repository:

# git clone https://github.com/OpenSCAP/openscap-daemon.git
# cd openscap-daemon/atomic
# docker build f24_spc
# atomic install

Alternatively, OpenSCAP can also be installed on the host:

# dnf install openscap-daemon
# systemctl enable oscapd.service
# systemctl start oscapd.service

The following example assumes that OpenSCAP should run within a container:

# atomic scan --list
Scanner: atomic_scan_openscap
    Image Name: docker.io/fedora/atomic_scan_openscap
    Scan type: cve *
    Description: Performs a CVE scan based on known CVE data

The default scan type checks containers and container images for known CVEs. However, this can be changed in the /etc/atomic.d/atomic_scan_openscap configuration file so that, for example, a scan runs on the basis of a certain policy. It is then very easy to scan an image or container by name or ID (Listing 1).

# atomic scan e3c6b87b8e7d
docker run -it --rm -v /etc/localtime:/etc/localtime -v /run/atomic/2016-10-31-10-55-19-332052:/scanin -v /var/lib/atomic/atomic_scan_openscap/2016-10-31-10-55-19-332052:/scanout:rw,Z -v /etc/oscapd:/etc/oscapd:ro docker.io/fedora/atomic_scan_openscap oscapd-evaluate scan --no-standard-compliance --targets chroots-in-dir:///scanin --output /scanout
e3c6b87b8e7d (e3c6b87b8e7d462)
The following issues were found:
RHSA-2016:1626: python security update (Moderate)
Severity: Moderate
 ** ** ** Associated CVEs:
 ** ** ** ** ** CVE ID: CVE-2016-0772
 ** ** ** ** ** CVE URL: https://access.redhat.com/security/cve/CVE-2016-0772
 ** ** ** ** ** CVE ID: CVE-2016-1000110
 ** ** ** ** ** CVE URL: https://access.redhat.com/security/cve/CVE-2016-1000110
 ** ** ** ** ** CVE ID: CVE-2016-5699
 ** ** ** ** ** CVE URL: https://access.redhat.com/security/cve/CVE-2016-5699
 ** ** ** RHSA URL: https://rhn.redhat.com/errata/RHSA-2016-1626.html
 ** ** ** RHSA ID: RHSA-2016:1626-00
[...]

Conclusions

With the help of Atomic and OpenSCAP, containers and container images can be checked very easily for vulnerabilities. Instead of trying to reinvent the wheel, OpenSCAP relies on well-defined standards. Thanks to the modular design of the Atomic tool, the OpenSCAP scanner can be addressed directly.