Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1570956 - Selecting "Standard System Security Profile" during install fails
Selecting "Standard System Security Profile" during install fails
Status: VERIFIED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: scap-security-guide (Show other bugs)
7.5
Unspecified Unspecified
medium Severity high
: rc
: ---
Assigned To: Watson Yuuma Sato
Marek Haicman
: Regression
: 1525251 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-23 16:19 EDT by Kyle Walker
Modified: 2018-09-25 15:22 EDT (History)
14 users (show)

See Also:
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:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3421631 None None None 2018-04-23 17:07 EDT

  None (edit)
Description Kyle Walker 2018-04-23 16:19:48 EDT
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 07:23:18 EDT
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-02 21:12:23 EDT
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 15:58:36 EDT
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 07:39:19 EDT
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 07:40:49 EDT
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 08:34:55 EDT
*** Bug 1525251 has been marked as a duplicate of this bug. ***
Comment 15 Marek Haicman 2018-09-16 17:55:14 EDT
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 18:21:14 EDT
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 18:48:49 EDT
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 01:02:35 EDT
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 04:45:50 EDT
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 :)

Note You need to log in before you can comment on or make changes to this bug.