System Security with OpenSCAP
Uyuni uses OpenSCAP to audit clients. It allows you to schedule and view compliance scans for any client.
OpenSCAP auditing is not available on Salt clients that use the SSH contact method.
Scanning clients can consume a lot of memory and compute power on the client being scanned. For Red Hat clients, ensure you have at least 2 GB of RAM available on each client to be scanned.
The Security Certification and Authorization Package (SCAP) is a standardized compliance checking solution for enterprise-level Linux infrastructures. It is a line of specifications maintained by the National Institute of Standards and Technology (NIST) for maintaining system security for enterprise systems.
SCAP was created to provide a standardized approach to maintaining system security, and the standards that are used continually change to meet the needs of the community and enterprise businesses. New specifications are governed by NIST’s SCAP Release cycle to provide a consistent and repeatable revision work flow. For more information, see http://scap.nist.gov/timeline.html.
Uyuni uses OpenSCAP to implement the SCAP specifications. OpenSCAP is an auditing tool that utilizes the Extensible Configuration Checklist Description Format (XCCDF). XCCDF is a standard way of expressing checklist content and defines security checklists. It also combines with other specifications such as Common Platform Enumeration (CPE), Common Configuration Enumeration (CCE), and Open Vulnerability and Assessment Language (OVAL), to create a SCAP-expressed checklist that can be processed by SCAP-validated products.
OpenSCAP verifies the presence of patches by using content produced by the SUSE Security Team. OpenSCAP checks system security configuration settings and examines systems for signs of compromise by using rules based on standards and specifications. For more information about the SUSE Security Team, see https://www.suse.com/support/security.
Before you begin, you need to prepare your client systems for SCAP scanning.
For traditional and Salt clients, install the
openscap-utils package before you begin.
Use this command to determine the location of the appropriate SCAP files. Take a note of the file paths for performing the scan:
rpm -ql openscap-content
For scanning Red Hat clients, install the
openscap-utils packages before you begin.
Use this command to determine the location of the appropriate SCAP files.
Take a note of the file paths for performing the scan:
rpm -ql scap-security-guide
OpenSCAP uses SCAP content files to define test rules.
These content files are created based on the XCCDF or OVAL standards.
You can download publicly available content files and customize it to your requirements.
You can install the
openscap-content package for default content file templates.
Alternatively, if you are familiar with XCCDF or OVAL, you can create your own content files.
We recommend you use templates to create your SCAP content files. If you create and use your own custom content files, you do so at your own risk. If your system becomes damaged through the use of custom content files, you might not be supported by SUSE.
When you have created your content files, you need to transfer the file to the client.
You can do this in the same way as you move any other file, using physical storage media, or across a network with
We recommend that you create a package to distribute content files to clients that you are managing with Uyuni. Packages can be signed and verified to ensure their integrity. For more information, see administration:custom-channels.adoc.
When you have transferred your content files, you can perform audit scans. Audit scans can be triggered using the Uyuni Web UI. You can also use the Uyuni API to schedule regular scans.
In the Uyuni Web UI, navigate toand select the client you want to scan.
Navigate to the
Audittab, and the
Path to XCCDF Documentfield, enter the path to the XCCDF content file on the client. For example:
The scan runs at the client’s next scheduled synchronization.
The XCCDF content file is validated before it is run on the remote system. If the content file includes invalid arguments, the test fails.
Before you begin, ensure that the client to be scanned has Python and XML-RPC libraries installed.
Choose an existing script or create a script for scheduling a system scan through
system.scap.scheduleXccdfScan. For example:
#!/usr/bin/python client = xmlrpclib.Server('https://spacewalk.example.com/rpc/api') key = client.auth.login('username', 'password') client.system.scap.scheduleXccdfScan(key, <1000010001>, '<path_to_xccdf_file.xml>', '--profile <profile_name>')
In this example: *
<1000010001>is the system ID (sid). *
<path_to_xccdf_file.xml>is the path to the content file location on the client. For example,
<profile_name>is an additional argument for the
oscapcommand. For example, use
Run the script on the client you want to scan, from the command prompt.
Information about the scans you have run is in the Uyuni Web UI. Navigate to to reference:audit/openscap-all-scans.adoc.for a table of results. For more information about the data in this table, see
To ensure that detailed information about scans is available, you need to enable it on the client.
In the Uyuni Web UI, navigate to
Configuration tab, and check the
Enable Upload of Detailed SCAP Files option.
When enabled, this generates an additional HTML file on every scan, which contains extra information.
The results show an extra line similar to this:
Detailed Results: xccdf-report.html xccdf-results.xml scap-yast2sec-oval.xml.result.xml
To retrieve scan information from the command line, use the
spacewalk-report system-history-scap spacewalk-report scap-scan spacewalk-report scap-scan-results
You can also use the Uyuni API to view results, with the