Bug 1570956

Summary: Selecting "Standard System Security Profile" during install fails
Product: Red Hat Enterprise Linux 7 Reporter: Kyle Walker <kwalker>
Component: scap-security-guideAssignee: Watson Yuuma Sato <wsato>
Status: CLOSED ERRATA QA Contact: Marek Haicman <mhaicman>
Severity: high Docs Contact:
Priority: medium    
Version: 7.5CC: bward, ctoppings, ddan39, jcastran, kheal, mhaicman, mpreisle, openscap-maint, pasik, pasteur, perobins, philip.wyett, rhbugs, thomas.oulevey
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: scap-security-guide-0.1.40-2.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-30 11:46:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Kyle Walker 2018-04-23 20:19:48 UTC
Description of problem:
  Selecting "Standard System Security Profile" during install fails with the following error:

    /dev/shm must be on a separate partition or logical volume

The Anaconda installer is calling the following when applying this profile within the "SECURITY POLICY" spoke:

    # oscap xccdf generate fix --template=urn:redhat:anaconda:pre --profile=xccdf_org.ssgproject.content_profile_standard /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml


Version-Release number of selected component (if applicable):
  7.5 Binary DVD Installation Media

How reproducible:
  Easily

Steps to Reproduce:
1. Begin an installation using the 7.5 Binary DVD media
2. Leave all options to their default
3. Select the "SECURITY POLICY" menu option
4. Select "Standard System Security Profile" from the menu presented
5. Click the "Select profile" button

Actual results:
  The "Changes that were done or need to be done:" field returns

    /dev/shm must be on a separate partition or logical volume 

Expected results:
  No error returned. Especially not an error related to the /dev/shm interface. This is not a configured mount point, but is created/mounted by systemd internals.

    https://github.com/lnykryn/systemd-rhel/blob/f3d485e1034cdea60cab3c257e340dd9b3e48fc1/src/core/mount-setup.c#L89

Additional info:
  The exact error being returned by oscap, and is translated by the installer, is the following:

~~~~
[anaconda root@unused /]# oscap xccdf generate fix --template=urn:redhat:anaconda:pre --profile=xccdf_org.ssgproject.content_profile_standard /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml                

part /dev/shm --mountoptions="nodev"

part /dev/shm --mountoptions="nosuid"
~~~~

Comment 5 Watson Yuuma Sato 2018-04-24 11:23:18 UTC
Hello, thank you for the detailed report.

Indeed, SSG generates Anaconda remediations for mount_options rules regarding mount point /dev/shm. And as mentioned /dev/shm is mounted during boot, and it cannot be remediate during install time.

Fix is to stop generating Anaconda remediations for mount_options rules for mount points in /dev/shm.

Comment 7 Anssi Johansson 2018-05-03 01:12:23 UTC
As far as I can see, the "C2S for Red Hat Enterprise Linux 7" profile is also affected by this.

Comment 8 Chadd Toppings 2018-07-25 19:58:36 UTC
Hi,

Are there any steps available as a workaround to apply security profiles when performing the initial RHEL 7.5 OS install?

Comment 9 Watson Yuuma Sato 2018-07-26 11:39:19 UTC
Hello Chadd,

It may not be easy workaround this.
One way I see is to make a customization that unselects the "xccdf_org.ssgproject.content_rule_mount_option_dev_shm_nosuid" and "nodev" rules, merge the customization into the datastream, and feed it through the network to oscap-anaconda-addon. More details here: https://bugzilla.redhat.com/show_bug.cgi?id=1479008#c7

Comment 10 Watson Yuuma Sato 2018-07-26 11:40:49 UTC
Last two commits of PR https://github.com/OpenSCAP/scap-security-guide/pull/3162 should fix this issue.

Comment 12 Watson Yuuma Sato 2018-08-01 12:34:55 UTC
*** Bug 1525251 has been marked as a duplicate of this bug. ***

Comment 15 Marek Haicman 2018-09-16 21:55:14 UTC
Verified fix in version scap-security-guide-0.1.40-5.el7

NEW (scap-security-guide-0.1.40-5.el7):
$ grep "^part /dev" /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
<no findings>

OLD (scap-security-guide-0.1.36-9.el7_5):
$ grep "^part /dev" /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml 
part /dev/shm --mountoptions="nodev"
part /dev/shm --mountoptions="noexec"
part /dev/shm --mountoptions="nosuid"
part /dev/shm --mountoptions="nodev"
part /dev/shm --mountoptions="noexec"
part /dev/shm --mountoptions="nosuid"

Comment 16 Anssi Johansson 2018-09-16 22:21:14 UTC
Note that ssg-rhel7-ds.xml is not the only file that was affected by this bug. Please check all .xml files in that directory.

Best regards,
someone from the CentOS QA team

Comment 17 Marek Haicman 2018-09-16 22:48:49 UTC
Hello Anssi,
RHEL7 package ships only these datastreams:
$ ls *ds.xml
ssg-firefox-ds.xml  ssg-jre-ds.xml  ssg-rhel6-ds.xml  ssg-rhel7-ds.xml

As far as I can tell, the only DS applicable to anaconda installation is rhel7 one.

If you are concerned about CentOS content, the way upstream handles centos (it's mostly a rebrand of rhel7 content, done by build system - no separate data sources) patches should be applicable there as well :)

Comment 18 Anssi Johansson 2018-09-17 05:02:35 UTC
I was referring to ssg-rhel7-xccdf.xml which also has(/had?) those entries, but perhaps it's okay to keep them in that catalog if they are still present. Yes, what CentOS does is not your concern, I'm just trying to make sure RHEL gets this right. If RHEL 7.6 installs using the "Standard System Security Profile" and "C2S for Red Hat Enterprise Linux 7" profiles work OK with the new scap-security-guide then everything's fine.

Comment 19 Marek Haicman 2018-09-17 08:45:50 UTC
Ah, I see. xccdf is one of the components in the datastream. For legacy reasons, we ship both DS, and exploded components (xccdf ,oval, cpe-*, ocil). These are no different, and thus checking DS means other files are ok as well.

Please note that due to specifics of SCAP Security Guide CPE usage, it's recommended to use datastreams wherever possible. (because if you use xccdf, you have to also explicitly use cpe dictionary shipped along it. (Anaconda uses datastreams for the same reasons for some time now)

Thank you for the double check, appreciated :)

Comment 21 errata-xmlrpc 2018-10-30 11:46:49 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3308