OpenSCAP on CentOS 7 – Installing from source

OpenSCAP on CentOS 7

Installing from source

Security automation is hot and we love it. One way is using the OpenSCAP toolkit. Unfortunately it is not mature enough, so you might want to build and install it from source. We share our findings while creating our test environment.

Install required components

On our minimum installed CentOS 7 system, we need to install a few components. Most are related to compiling C++ and parsing XML files. Since we like to use Git, let’s start with that and obtain the source code of OpenSCAP:

mkdir /root/openscap-build && cd /root/openscap-build
yum install git
git clone
cd openscap/

Next is installing the related components to build the toolkit:

yum install gcc
yum install autoconf automake libtool
yum install libcurl-devel libxml2-devel libxslt-devel pcre-devel swig
yum install python-devel

Optional components

To support as much as possible, we want to install some additional components. They are not needed for everything, but depending on the system may be useful (e.g. RPM for CentOS).

yum install rpm-devel libselinux-devel systemd-devel GConf2-devel

We skip isaconf, as this is related to Solaris.

Build OpenSCAP from source

Time to build OpenSCAP from the source files:

make clean && ./ && ./configure && make

If everything went fine, it should end with leaving the directories and a successful compilation (something like this):

make[3]: Leaving directory `/root/openscap/openscap/swig/python2'
Making all in python3
make[3]: Entering directory `/root/openscap/openscap/swig/python3'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/root/openscap/openscap/swig/python3'
make[3]: Entering directory `/root/openscap/openscap/swig'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/root/openscap/openscap/swig'
make[2]: Leaving directory `/root/openscap/openscap/swig'
make[2]: Entering directory `/root/openscap/openscap'
make[2]: Leaving directory `/root/openscap/openscap'
make[1]: Leaving directory `/root/openscap/openscap'

So if the build was successful, we can optionally install the toolkit:

make install

In our case there are some builds between what the original CentOS 7 package provided and the newer compiled binary in /usr/local/bin:

[root@localhost openscap]# /bin/oscap -V | grep oscap
OpenSCAP command line tool (oscap) 1.0.3
[root@localhost openscap]# /usr/local/bin/oscap -V | grep oscap
OpenSCAP command line tool (oscap) 1.2.0

Happy auditing!



Yum plugins: Available plugins and built-in security support

Enhancing yum

Determine available plugins and built-in security support

To enhance the support in our auditing tool Lynis, we wanted to know if yum supports security related functions by using a plugin or having it as built-in functionality.


Yum, or Yellowdog Updater Modified, is a software management tool for Linux based systems. Usually it is used on systems running SuSE or Red Hat based (like RHEL, Fedora or CentOS). Plugins extend the functionality of yum, to improve its functionality.

One plugin may select the fastest software mirror, so you don’t have to benchmark them manually. Another great plugin helps with security and shows what security related updates are available. Nowadays, this functionality is built-in, as the demand for this functionality is huge.

In our case we want to audit the yum tool set and determine if we have the plugin available, or dealing with the built-in functions. Let’s start with the plugins..

Yum plugins

We can query the repository for packages which put files in the /usr/lib/yum-plugins directory. We have two options for that, using yum provides, or the repoquery utility.

yum provides "/usr/lib/yum-plugins/*"
 Loaded plugins: fastestmirror
 Loading mirror speeds from cached hostfile
 * base:
 * extras:
 * updates:
 PackageKit-yum-plugin-0.8.9-11.el7.centos.x86_64 : Tell PackageKit to check for updates when yum exits
 Repo        : base
 Matched from:
 Filename    : /usr/lib/yum-plugins/
 Filename    : /usr/lib/yum-plugins/refresh-packagekit.pyo
 Filename    : /usr/lib/yum-plugins/refresh-packagekit.pyc
kabi-yum-plugins-1.0-2.el7.centos.noarch : The CentOS Linux kernel ABI yum plugin
 Repo        : base
 Matched from:
 Filename    : /usr/lib/yum-plugins/
 Filename    : /usr/lib/yum-plugins/kabi.pyo
 Filename    : /usr/lib/yum-plugins/kabi.pyc
subscription-manager-1.10.14-7.el7.centos.x86_64 : Tools and libraries for subscription and repository management
 Repo        : base
 Matched from:
 Filename    : /usr/lib/yum-plugins/subscription-manager.pyc
 Filename    : /usr/lib/yum-plugins/subscription-manager.pyo
 Filename    : /usr/lib/yum-plugins/
 Filename    : /usr/lib/yum-plugins/product-id.pyc
 Filename    : /usr/lib/yum-plugins/
 Filename    : /usr/lib/yum-plugins/product-id.pyo

Besides the interesting file paths, it doesn’t give much more pointers at this moment. Lets try repoquery:

[root@localhost Lynis]# repoquery -f "/usr/lib/yum-plugins/*" | sort | uniq

Built-in support

Since the security plugin does not show up in any of these listings, we use the discovered file path. Searching in this directory shows the existing yum plugins:

[root@localhost Lynis]# find /usr/lib/yum-plugins/

It is clear only fastestmirror is available. Let’s analyze the yum binary.

[root@localhost Lynis]# file /usr/bin/yum
 /usr/bin/yum: Python script, ASCII text executable
[root@localhost Lynis]# grep -i security /usr/bin/yum

No hit, so we have to look inside the Python script:

[root@localhost Lynis]# cat /usr/bin/yum
import sys
    import yum
except ImportError:
    print >> sys.stderr, """\
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:


Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:

If you cannot solve this problem yourself, please go to
the yum faq at:

""" % (sys.exc_value, sys.version)

sys.path.insert(0, '/usr/share/yum-cli')
    import yummain
    yummain.user_main(sys.argv[1:], exit_code=True)
except KeyboardInterrupt, e:
    print >> sys.stderr, "\n\nExiting on user cancel."

By catting the file we can see it includes the /usr/share/yum-cli directory. Grepping through this directory quickly shows one pointer on how to detect if we have security support built-in.

[root@localhost Lynis]# grep -r security /usr/share/yum-cli
 /usr/share/yum-cli/            self.base.updateinfo_filters['security'] =
 /usr/share/yum-cli/        group.add_option("--security", action="store_true",
 /usr/share/yum-cli/                help=_("Include security relevant packages, in updates"))
 /usr/share/yum-cli/                help=_("Include security relevant packages matching the severity, in updates"))
 Binary file /usr/share/yum-cli/cli.pyc matches
 /usr/share/yum-cli/                   'list-security'      : 'list',
 /usr/share/yum-cli/                   'info-security'      : 'info',
 /usr/share/yum-cli/        return "[info|list|...] [security|...] [installed|available|all] [pkgs|id]"
 /usr/share/yum-cli/            if tn == 'security' and notice['severity']:
 /usr/share/yum-cli/            if tn == 'security' and notice['severity']:
 /usr/share/yum-cli/            if notice['type'] == 'security':
 /usr/share/yum-cli/        for T in ('newpackage', 'security', 'bugfix', 'enhancement'):
 /usr/share/yum-cli/                'security' : 'Security',
 /usr/share/yum-cli/        for T in ('newpackage', 'security', 'bugfix', 'enhancement'):
 /usr/share/yum-cli/            if T == 'security' and len(sev_counts) == 1:
 /usr/share/yum-cli/            if T == 'security' and len(sev_counts) != 1:
 /usr/share/yum-cli/                    args = (maxsize, sev_counts[sn],sn or '?', outT['security'])
 /usr/share/yum-cli/                 "sec" : "security",
 Binary file /usr/share/yum-cli/yumcommands.pyc matches

Great, this provides at least some guidance. For now we use the line with group.add_option to determine that support is built into the yum toolset itself. This enables checking for yum plugins and built-in support.


PCI DSS (v3) Linux: Restrict log file viewing (A.1.2.d)

Restrict log file viewing

A.1.2.d Verify that viewing of log entries is restricted to the owning

To limit exposure to information, PCI DSS requires access of logging to only the entity owning that log file. In other words, we have to search for those entries which can be seen by others.

Search related log files

By default, most log files on Linux based systems will be stored in /var/log. We can do a quick check for any files which are world readable, by using find.

find /var/log -perm -o=r ! -type l

This will show all files in /var/log or any subdirectory where the other group has read permissions. We skip any symbolic links, as they will show up otherwise.

Changing permissions

Usually it is easy to restrict log file viewing of these entries by changing file permissions. Depending on the software used, it might be wise to test altering the permissions, restart the process and test if the software can continue to work properly.

chmod 640 /var/log/

Also tools like logrotate might create new log files with inappropriate permissions. So this control has to be reviewed on a regular basis. It is preferred to use an automated solution to test.

Some files may need an exception, like /var/log/wtmp. Running the last command will result in a permission denied error.

user@host:~$ last
last: /var/log/wtmp: Permission denied

This information is provided as an addition to the PCI DSS plugin for Lynis.

« Older Entries