Recently on the Red Hat Developers blog, I wrote about the re-architecture of the atomic vulnerability scan feature. The primary function of atomic scan is to detect vulnerabilities in your images and containers using a plug-in enabled architecture.

Building upon that concept, we added an additional feature to atomic scan where you can now pass a chroot to it for the purposes of scanning. One immediate benefit from this change was that we can now use the same scanner for our images and containers to scan a virtual machine (VM) that has been mounted onto the host’s filesystem.

In this blog, I will show you how to scan a live VM with atomic scan.

Check for a Running VM

The first step is to see what VMs are on your system. In my case, I have two VMs running; one of which was created for this purpose based on a RHEL 7.2 stock install with no updates.

[bbaude@localhost ~]$ sudo virsh list
 Id    Name                           State
 4     rhel7-scan                     running
 5     centos                         running

The VM I want to work with is called rhel7-scan.

Check the Filesystems in the VM

To mount a live VM to our filesystem, I plan to use a couple of applications from the libguestfs package. While we do know which VM (sometimes referred to as a virtual domain) we want to work with, mounting VMs requires some basic knowledge of the VM’s fileystems; specifically, we want to know more about the VM’s root filesystem. We can use virt-filesystems to probe the VM’s filesystems.

[bbaude@localhost ~]$ sudo virt-filesystems -d rhel7-scan
[bbaude@localhost ~]$

We now know the device associated with the root filesystem is /dev/rhel/root. This is a required piece of information for mounting VMs.

Mount the VM’s Root Filesystem

The first step is to create a directory where the VM’s root filesystem will reside after mounting. In this case, I am going to simply create a directory called /tmp/rhel.

[bbaude@localhost ~]$ mkdir /tmp/rhel

Now, armed with the VM’s name (or domain) and the root filesystem’s device, we can use guestmount to actually perform the mount. Note here because the VM is live, I have choosen to mount the filesystem as read-only. I also happen to know that the scanner does not need to write any files to the VM filesystem so read-only is appropriate.

[bbaude@localhost ~]$ sudo guestmount  -d rhel7-scan -m /dev/rhel/root --ro /tmp/rhel

The VM’s root filesystem is now mounted and we can use ls to take a peek at the chroot.

[bbaude@localhost ~]$ sudo ls -l /tmp/rhel
total 28
lrwxrwxrwx.  1 root root    7 May 11  2016 bin -> usr/bin
drwxr-xr-x.  2 root root    6 May 11  2016 boot
drwxr-xr-x.  2 root root    6 May 11  2016 dev
drwxr-xr-x. 77 root root 8192 May 11  2016 etc
drwxr-xr-x.  3 root root   18 May 11 13:48 home
lrwxrwxrwx.  1 root root    7 May 11  2016 lib -> usr/lib
lrwxrwxrwx.  1 root root    9 May 11  2016 lib64 -> usr/lib64
drwxr-xr-x.  2 root root    6 May 25  2015 media
drwxr-xr-x.  2 root root    6 May 25  2015 mnt
drwxr-xr-x.  2 root root    6 May 25  2015 opt
drwxr-xr-x.  2 root root    6 May 11  2016 proc
dr-xr-x---.  2 root root 4096 May 11 13:49 root
drwxr-xr-x.  2 root root    6 May 11  2016 run
lrwxrwxrwx.  1 root root    8 May 11  2016 sbin -> usr/sbin
drwxr-xr-x.  2 root root    6 May 25  2015 srv
drwxr-xr-x.  2 root root    6 May 11  2016 sys
drwxrwxrwt.  7 root root 4096 May 11  2016 tmp
drwxr-xr-x. 13 root root 4096 May 11  2016 usr
drwxr-xr-x. 19 root root 4096 May 11  2016 var

Prepare to Scan the Mounted Filesystem

Before we jump into scanning the filesystem, you should verify what scanners (plug-ins) are installed for atomic. As my previous blog has shown, you can simply use atomic scan –list to see what scanners are currently configured for you.

[bbaude@localhost ~]$ sudo atomic scan --list
Scanner: openscap *
  Image Name: openscap
     Scan type: cve *
     Description: Performs a CVE scan based on known CVE data

     Scan type: standards_compliance
     Description: Performs a standard scan

* denotes defaults

Based on this output, there is only one scanner available. It is called openscap and has two different scans avilable: cve and standards_compliance. The cve scan is the noted as the default.

If you are not familiar with the atomic scan function, you can simply learn more with the –help switch or read the man page. The key item we need to know about is the –rootfs command line switch. This switch requires a filesystem path as a value.

[bbaude@localhost ~]$ sudo atomic scan --help
usage: atomic scan [-h] [--scanner {openscap}] [--scan_type SCAN_TYPE]
                   [--list] [--verbose] [--rootfs [ROOTFS] | --all | --images
                   | --containers]
                   [scan_targets [scan_targets ...]]

positional arguments:
  scan_targets          container image

optional arguments:
  -h, --help            show this help message and exit
  --scanner {openscap}  define the intended scanner
  --scan_type SCAN_TYPE
                        define the intended scanner
  --list                List available scanners
  --verbose             Show more output from scanning container
  --rootfs [ROOTFS]     Rootfs path to scan
  --all                 scan all images (excluding intermediate layers) and
  --images              scan all images (excluding intermediate layers)
  --containers          scan all containers

atomic scan <input> scans a container or image for CVEs

Scan the Filesystem Using Atomic Scan

At this point, we have all the information we need to perform the scan. It is now only a matter of executing the command properly. The command syntax is simply atomic scan –rootfs . You can also enable the –verbose command line switch to see more output, which is good for debug purposes.

Note: Because I already have the openscap image pulled locally, you will not see it being pulled. Of course, if you do not have the image local, your output will vary slightly.

[bbaude@localhost ~]$ sudo atomic scan --rootfs /tmp/rhel
docker run -it --rm -v /etc/localtime:/etc/localtime -v /run/atomic/2016-05-11-13-54-05-804238:/scanin -v /var/lib/atomic/openscap/2016-05-11-13-54-05-804238:/scanout:rw,Z --security-opt label:disable openscap oscapd-evaluate scan --no-standard-compliance --targets chroots-in-dir:///scanin --output /scanout

/tmp/rhel (/tmp/rhel)

The following issues were found:

     RHSA-2016:1025: pcre security update (Important)
     Severity: Important
       RHSA URL:
       RHSA ID: RHSA-2016:1025-00
       Associated CVEs:
           CVE ID: CVE-2015-2328
           CVE URL:
           CVE ID: CVE-2015-3217
           CVE URL:
           CVE ID: CVE-2015-5073
           CVE URL:
           CVE ID: CVE-2015-8385
           CVE URL:
           CVE ID: CVE-2015-8386
           CVE URL:
           CVE ID: CVE-2015-8388
           CVE URL:
           CVE ID: CVE-2015-8391
           CVE URL:
           CVE ID: CVE-2016-3191
           CVE URL:

     RHSA-2016:0722: openssl security update (Important)
     Severity: Important
       RHSA URL:
       RHSA ID: RHSA-2016:0722-00
       Associated CVEs:
           CVE ID: CVE-2016-0799
           CVE URL:
           CVE ID: CVE-2016-2105
           CVE URL:
           CVE ID: CVE-2016-2106
           CVE URL:
           CVE ID: CVE-2016-2107
           CVE URL:
           CVE ID: CVE-2016-2108
           CVE URL:
           CVE ID: CVE-2016-2109
           CVE URL:
           CVE ID: CVE-2016-2842
           CVE URL:

     RHSA-2016:0685: nss, nspr, nss-softokn, and nss-util security, bug fix, and enhancement update (Moderate)
     Severity: Moderate
       RHSA URL:
       RHSA ID: RHSA-2016:0685-00
       Associated CVEs:
           CVE ID: CVE-2016-1978
           CVE URL:
           CVE ID: CVE-2016-1979
           CVE URL:

Content removed due to length

Files associated with this scan are in /var/lib/atomic/openscap/2016-05-11-13-54-05-804238.

As you can see, there are least three vulnerabilities caught here. The rest were clipped in the interest of space.

Unmount the VM’s Filesystem

Don’t forget to unmount the VM’s filesystem when your scan is complete. In my case, I want to remediate the VM to shore up the vulnerabilties.

[bbaude@localhost ~]$ sudo guestunmount /tmp/rhel

Remediate the Vulnerabilties and Rescan

As I said earlier, this VM we scanned was based on a stock RHEL7.2 install without any updates. This was obviously done on purpose to demonstrate the scan first. I then logged into the VM and updated the system entirely and will now remount the VM filesystem and rescan.

[bbaude@localhost ~]$ sudo guestmount  -d rhel7-scan -m /dev/rhel/root --ro /tmp/rhel
[bbaude@localhost ~]$ sudo atomic scan --rootfs /tmp/rhel
docker run -it --rm -v /etc/localtime:/etc/localtime -v /run/atomic/2016-05-12-10-55-44-763361:/scanin -v /var/lib/atomic/openscap/2016-05-12-10-55-44-763361:/scanout:rw,Z --security-opt label:disable openscap oscapd-evaluate scan --no-standard-compliance --targets chroots-in-dir:///scanin --output /scanout

/tmp/rhel (/tmp/rhel)

/tmp/rhel passed the scan

Files associated with this scan are in /var/lib/atomic/openscap/2016-05-12-10-55-44-763361.

[bbaude@localhost ~]$ sudo guestunmount /tmp/rhel
[bbaude@localhost ~]$  

The scan is clean and no vulnerabilities are found.

Using the atomic scan function with the openSCAP project is not only an easy way to find vulnerabilities in your RHEL based images and containers, but it can basically scan and chroot filesystem that is RHEL including read-only mounts of VM root filesystems. It is a quick, singular way to perform the scan.