Security Compliance : true
We recently released Oracle VM Server for x86 3.2.7. For more information you can go here. In addition we also recently released Oracle Linux 6.5. Find the press release here and the link to the release notes here.You will notice that for Oracle Linux we have updated the version of OpenSCAP to use the NIST SCAP 1.2 specification.
We have also decided to distribute OpenSCAP with Oracle VM Server for x86 so you will be able to use the same utility for security compliance checks that you may use with Oracle Linux and Oracle Solaris. Initially, the OpenSCAP package we are distributing with Oracle VM Server for x86 is available on the Oracle Public Yum Server, so you may start by using the oscap(8) - OpenSCAP command line tool after you've installed the openscap-utils RPM on your Dom0 test environment. If you are working on the technical security controls that are required by your organization for the approval to operate Oracle VM Server for x86, then you should understand that OpenSCAP is an effective tool to demonstrate security compliance to your authorizing official. However, you should carefully examine your organizations SCAP content and the implementation details such as the use of OVAL for compliance checks.
We typically recommend that you do not directly execute additional utilities within the Oracle VM Server management domain (i.e. the Dom0 domain), but checking security compliance requires careful limited access by your authorized administrators to produce the reports. The Oracle VM Security Guide for Release 3 explains the philosophy of protection for the installation of the Oracle VM Server using a small footprint:
"Oracle VM Server runs a lightweight, optimized version of Oracle Linux. It is based upon an updated version of the Xen hypervisor technology and includes Oracle VM Agent. The installation of Oracle VM Server in itself is secure: it has no unused packages or applications and no services listening on any ports except for those required for the operation of the Oracle VM environment."
Please note that you should report any potential security vulnerabilities in Oracle products following the instructions found here.
We posted some helpful details about Oracle Linux Errata and CVE information this time last year and you may also review the notifications of Oracle VM errata here. For the examples we are reviewing now, the use of OVAL checks is a part the traditional ways you would show that your servers are all compliant (locked-down or hardened) with relevant security settings in your checklists that reference the product security guides.
The Oracle Software Security Assurance Secure Configuration Initiative has established Oracle product security goals for both Secure Configuration and Security Guides. We have built in the security features with Oracle VM Server for x86 and you should expect that the default installation follows the software security assurance guidelines. Using OpenSCAP for security compliance checks may help you to show that the Oracle VM Server for x86 configuration is up to date with the latest details documented in the security guides for operating systems and server virtualization.
A standardized approach to security compliance is a goal that many organizations are working toward and includes a broad set of security controls typically found within a complete Risk Management Framework provided by the NIST RMF and other standards bodies within the international IT security community. When you begin to use OpenSCAP you will find that the standard SCAP content contains product specific technical security controls that are expected to be unique and have version dependencies as well. You will notice the standard SCAP content used with OpenSCAP on Oracle VM Server for x86 can produce valid securty compliance reports, but you must still understand the technical nuances for measuring compliance that show results for each test:
True
False
Error
Unknown
Not Applicable
Not EvaluatedAdvantages to using a standardized approach for security compliance include considerations of "what is measured" and "how it is measured" to improve the precision, accuracy and ultimate effectiveness required to mitigate risks. The initial results that are produced using OpenSCAP for security compliance checks must be further examined to truly understand the meaning of 'true' or 'false' so that you can demonstrate the rationalization for applying any fixes to re-mediate a verifiable problem. The effectiveness of OpenSCAP depends on the thorough understanding of all the technical details at the early stages of your testing, so you will benefit by the complete coverage that may be repeated for all of your production Oracle VM Servers.
Automating system administration activities is a fundamental objective for on-premise and cloud computing architectures and we are working to standardize as much of the enterprise infrastructure components as possible to produce the most cost effective solutions using Oracle VM Server. The security compliance requirements of many organizations have increased reporting cycles that must be continuously monitored. With careful planning, OpenSCAP may be an effective tool for reporting your organizations IT security controls, but we want to review some of the basic concepts that you should be aware of.
We noted earlier that Dom0 is a special purpose management domain that is based on Xen built with Oracle Linux. The Oracle Linux and Oracle Solaris configurations share a common set of technical security controls that are useful to measure consistently with Oracle VM Server. However, the results you analyse requires historic perspectives and current insight to determine the relevance and criticality that is important to convey to the decision makers or authorizing officials in your organization.
One random example of a security compliance check that illustrates a number of considerations is related to CWE-264: Permissions, Privileges, and Access Controls. More specifically, as an exercise, we want to drill down to both CWE-275: Permission Issues and CWE-426: Untrusted Search Path potential problems.
To demonstrate how OpenSCAP can be used to report the results of a check related to CWE-275 and CWE-426 we can start by viewing the Red Hat 5 STIG Benchmark, Version 1, Release 4 from DISA:
[root@ovm327 ~]# wget http://iase.disa.mil/stigs/os/unix/u_redhat_5_v1r4_stig_benchmark.zip
For brevity, we have extracted out the OVAL compliance item for 'STIG ID: GEN000960' that we show using the DISA STIG Viewer:
If you also want to test this, here is the raw XML
This looks simple enough, so let's see the result using OpenSCAP on Oracle VM Server for x86:
[root@ovm327 ~]# oscap oval eval GEN000960.xml Definition oval:mil.disa.fso.rhel:def:77: true Evaluation done. [root@ovm327 ~]#
We think we understand the result but let's view this differently just to be sure:
[root@ovm327 ~]# ls -ldL `echo $PATH | tr ':''\n'` ls: /root/bin: No such file or directory drwxr-xr-x 2 root root 4096 Jan 2 12:45 /bin drwxr-xr-x 2 root root 4096 Jan 2 12:45 /sbin drwxr-xr-x 3 root root 16384 Jan 2 12:45 /usr/bin drwxr-xr-x 2 root root 4096 Feb 16 2010 /usr/local/bin drwxr-xr-x 2 root root 4096 Feb 16 2010 /usr/local/sbin drwxr-xr-x 2 root root 12288 Jan 2 12:45 /usr/sbin [root@ovm327 ~]#
This looks good to us, but let's make the '/root/bin' directory that we intentionally want to violate the compliance check to see what happens:
[root@ovm327 ~]# mkdir -m 0777 /root/bin [root@ovm327 ~]# ls -ldL `echo $PATH | tr ':''\n'` drwxr-xr-x 2 root root 4096 Jan 2 12:45 /bin drwxrwxrwx 2 root root 4096 Jan 2 13:55 /root/bin drwxr-xr-x 2 root root 4096 Jan 2 12:45 /sbin drwxr-xr-x 3 root root 16384 Jan 2 12:45 /usr/bin drwxr-xr-x 2 root root 4096 Feb 16 2010 /usr/local/bin drwxr-xr-x 2 root root 4096 Feb 16 2010 /usr/local/sbin drwxr-xr-x 2 root root 12288 Jan 2 12:45 /usr/sbin [root@ovm327 ~]# oscap oval eval GEN000960.xml Definition oval:mil.disa.fso.rhel:def:77: false Evaluation done. [root@ovm327 ~]#
We have reasonably good confirmation that the OVAL compliance check works the way we expect. However, if we look at the entire set of permissions that enforce the discretionary access control policy, we then realize that there are also permissions on the '/root' directory that prevent the write operations by 'others' in the '/root/bin' directory from succeeding:
[root@ovm327 ~]# ls -ldL /root /root/bin drwxr-x--- 4 root root 4096 Jan 2 13:55 /root drwxrwxrwx 2 root root 4096 Jan 2 13:55 /root/bin [root@ovm327 ~]#
We are not suggesting that the mode '0777' permissions on the '/root/bin' are acceptable because we have safer permissions on the '/root' directory, but the example shows that the OVAL check does not completely test the security controls exactly how the kernel enforces the permissions. We should justifiably state that the result of the OVAL security compliance check '0777' permissions on the '/root/bin' directory is a 'condition negative' with a 'test outcome negative' (i.e. a true negative), but also continue to note our other observations related to the access control enforcement.
Before proceeding, we will clean up the problem we just temporarily created on our test server:
[root@ovm327 ~]# chmod 0700 /root/bin [root@ovm327 ~]# ls -ldL /root /root/bin drwxr-x--- 4 root root 4096 Jan 2 13:55 /root drwx------ 2 root root 4096 Jan 2 13:55 /root/bin [root@ovm327 ~]# oscap oval eval GEN000960.xml Definition oval:mil.disa.fso.rhel:def:77: true Evaluation done. [root@ovm327 ~]#
Hopefully you find this random security compliance check interesting and somewhat enlightening to illustrate what OpenSCAP can help you with. To continue, we decided to check a slightly different way to demonstrate the same security control:
[root@ovm327 ~]# wget https://git.fedorahosted.org/cgit/openscap.git/plain/dist/fedora/scap-fedora14-oval.xml
To simplify viewing the portion of the OVAL compliance entry we extracted it like we did with the DISA STIG item. If you also want to test this, here is the raw XML
Now we can show similar results using a slightly different implementation of the compliance check:
[root@ovm327 ~]# oscap oval eval fedora-accounts_root_path_dirs_no_write.xml Definition oval:org.open-scap.f14:def:200855: true Evaluation done. [root@ovm327 ~]# chmod 0770 /root/bin [root@ovm327 ~]# oscap oval eval fedora-accounts_root_path_dirs_no_write.xml Definition oval:org.open-scap.f14:def:200855: false Evaluation done. [root@ovm327 ~]#
But we can also see that it is indeed a different check because it includes the test for group write permissions and the 'STIG ID: GEN000960' does not:
[root@ovm327 ~]# chmod 0770 /root/bin [root@ovm327 ~]# oscap oval eval GEN000960.xml Definition oval:mil.disa.fso.rhel:def:77: true Evaluation done. [root@ovm327 ~]#
Again, let's fix the problem we temporarily created on our test server:
[root@ovm327 ~]# chmod 0700 /root/bin [root@ovm327 ~]#
You should also review the CIS Oracle Solaris 11.1 Benchmark v1.0.0 and the CIS Red Hat Enterprise Linux 6 Benchmark v1.2.0 to see that they both have the same entry to 'Ensure root PATH Integrity (Scored)' that has an audit section showing script commands that step through multiple potential security compliance issues to check. It is a common practice to combine similar checks in a group, but you may need to parse out the results to obtain a discrete value for a singular check.
As an additional consideration, let's shift our focus away from the differences within OVAL compliance definitions, to the different operating systems that the SCAP content was orignially written for. For this part of our testing we start up an Oracle Solaris 11.1 X86 instance running on a VM to demonstrate the OpenSCAP tests with the same OVAL compliance checks:
root@sol11:/root# pkg install security/compliance/openscap root@sol11:/root# ls -ldL `echo $PATH | tr ':''\n'` drwxr-xr-x 4 root bin 1126 Jan 2 14:05 /usr/bin drwxr-xr-x 4 root bin 445 Jan 2 13:54 /usr/sbin root@sol11:/root# oscap oval eval GEN000960.xml Definition oval:mil.disa.fso.rhel:def:77: true Evaluation done. root@sol11:/root# oscap oval eval fedora-accounts_root_path_dirs_no_write.xml Definition oval:org.open-scap.f14:def:200855: true Evaluation done. root@sol11:/root# export PATH=$PATH:/tmp root@sol11:/root# ls -ldL `echo $PATH | tr ':''\n'` drwxrwxrwt 5 root sys 432 Jan 2 14:09 /tmp drwxr-xr-x 4 root bin 1126 Jan 2 14:05 /usr/bin drwxr-xr-x 4 root bin 445 Jan 2 13:54 /usr/sbin root@sol11:/root# oscap oval eval GEN000960.xmlDefinition oval:mil.disa.fso.rhel:def:77: false Evaluation done. root@sol11:/root# oscap oval eval fedora-accounts_root_path_dirs_no_write.xml Definition oval:org.open-scap.f14:def:200855: false Evaluation done. root@sol11:/root#
Now let's repeat the same OpenSCAP checks with a non-root user account:
admin@sol11:~$ ls -ldL `echo $PATH | tr ':''\n'` drwxr-xr-x 4 root bin 1126 Jan 2 14:05 /usr/bin drwxr-xr-x 4 root bin 445 Jan 2 13:54 /usr/sbin admin@sol11:~$ oscap oval eval GEN000960.xml Definition oval:mil.disa.fso.rhel:def:77: true Evaluation done. admin@sol11:~$ oscap oval eval fedora-accounts_root_path_dirs_no_write.xml Definition oval:org.open-scap.f14:def:200855: true Evaluation done. admin@sol11:~$ export PATH=$PATH:/tmp admin@sol11:~$ ls -ldL `echo $PATH | tr ':''\n'` drwxrwxrwt 5 root sys 432 Jan 2 14:09 /tmp drwxr-xr-x 4 root bin 1126 Jan 2 14:05 /usr/bin drwxr-xr-x 4 root bin 445 Jan 2 13:54 /usr/sbin admin@sol11:~$ oscap oval eval GEN000960.xml Definition oval:mil.disa.fso.rhel:def:77: false Evaluation done. admin@sol11:~$ oscap oval eval fedora-accounts_root_path_dirs_no_write.xml Definition oval:org.open-scap.f14:def:200855: false Evaluation done. admin@sol11:~$
We have discovered some additional interesting considerations when reviewing the OpenSCAP results executed on Oracle Solaris:
The OVAL content appears to also work on Oracle Solaris 11.1
The OVAL check is on the current PATH environment variable
The OVAL check is for the current user shell or cron(1M) process running oscap(8)
The OVAL check does not look for scripts that set the PATH for application run time environments
The OVAL check does not account for more sophisticated access control technologyTo further our understanding of the OVAL content, we decided to run the jOVAL tool which is not included with Oracle Solaris:
admin@sol11:~$ echo $PATH
/usr/bin:/usr/sbin:/tmp
admin@sol11:~$ /usr/share/jOVAL/jovaldi -l 1 -m -o GEN000960.xml
----------------------------------------------------
jOVAL Definition Interpreter
Version: 5.10.1.2
Build date: Thursday, January 2, 2014 04:46:39 PM PST
Copyright (c) 2011-2013 - jOVAL.org
Plugin: Default Plugin
Version: 5.10.1.2
Copyright (C) 2011-2013 - jOVAL.org
----------------------------------------------------
Start Time: Fri Jan 02 16:50:05 2014
** parsing /home/admin/GEN000960.xml
- validating xml schema.
** checking schema version
- Schema version - 5.4
** skipping Schematron validation
** creating a new OVAL System Characteristics file.
** gathering data for the OVAL definitions.
Collecting object: FINISHED
** saving data model to system-characteristics.xml.
** skipping Schematron validation
** running the OVAL Definition analysis.
Analyzing definition: FINISHED
** OVAL definition results.
OVAL Id Result
-------------------------------------------------------
oval:mil.disa.fso.rhel:def:77 true
-------------------------------------------------------
** finished evaluating OVAL definitions.
** saving OVAL results to results.xml.
** skipping Schematron validation
** running OVAL Results xsl: /usr/share/jOVAL/xml/results_to_html.xsl.
----------------------------------------------------
admin@sol11:~$ echo $PATH
/usr/bin:/usr/sbin:/tmp
admin@sol11:~$ /usr/share/jOVAL/jovaldi -l 1 -m
-o fedora-accounts_root_path_dirs_no_write.xml
----------------------------------------------------
jOVAL Definition Interpreter
Version: 5.10.1.2
Build date: Thursday, January 2, 2014 04:46:39 PM PST
Copyright (c) 2011-2013 - jOVAL.org
Plugin: Default Plugin
Version: 5.10.1.2
Copyright (C) 2011-2013 - jOVAL.org
----------------------------------------------------
Start Time: Fri Jan 02 16:50:30 2014
** parsing /home/admin/fedora-accounts_root_path_dirs_no_write.xml
- validating xml schema.
** checking schema version
- Schema version - 5.5
** skipping Schematron validation
** creating a new OVAL System Characteristics file.
** gathering data for the OVAL definitions.
Collecting object: FINISHED
** saving data model to system-characteristics.xml.
** skipping Schematron validation
** running the OVAL Definition analysis.
Analyzing definition: FINISHED
** OVAL definition results.
OVAL Id Result
-------------------------------------------------------
oval:org.open-scap.f14:def:200855 false
-------------------------------------------------------
** finished evaluating OVAL definitions.
** saving OVAL results to results.xml.
** skipping Schematron validation
** running OVAL Results xsl: /usr/share/jOVAL/xml/results_to_html.xsl.
----------------------------------------------------
admin@sol11:~$
For now, this concludes our initial investigation of OpenSCAP to show the potential effectiveness on Oracle VM Server for x86 with careful consideration of the results you may observe with your SCAP content. You will also want to understand the XCCDF security checklists that are most often used to perform more complete security compliance checks with OpenSCAP in the same way you can check for STIG compliance:
# oscap xccdf eval --profile stig-rhel6-server --report report.html --results results.xml --cpe ssg-rhel6-cpe-dictionary.xml ssg-rhel6-xccdf.xml
We hope that the random security compliance example we chose will help to illustrate that the use of OpenSCAP is not a substitute for adequately proficient expertise for analyzing IT security controls, but it allows for the repetitive checks in your production Oracle VM Servers after you have completed sufficient testing. Please contact your Oracle representitives if you have any quetions or place service requests with Oracle Support when you encounter problems.
Finally, please remember that you should report any potential security vulnerabilities in Oracle products following the instructions found here.