RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1570956 - Selecting "Standard System Security Profile" during install fails
Summary: Selecting "Standard System Security Profile" during install fails
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: scap-security-guide
Version: 7.5
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: rc
: ---
Assignee: Watson Yuuma Sato
QA Contact: Marek Haicman
URL:
Whiteboard:
: 1525251 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-23 20:19 UTC by Kyle Walker
Modified: 2021-12-10 16:01 UTC (History)
14 users (show)

Fixed In Version: scap-security-guide-0.1.40-2.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 11:46:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3421631 0 None None None 2018-04-23 21:07:29 UTC
Red Hat Product Errata RHBA-2018:3308 0 None None None 2018-10-30 11:47:33 UTC

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
Note You need to log in before you can comment on or make changes to this bug.