Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1357620 - oscap report - false positives for gnome message-banner-text using 'stig-rhel7-server-upstream' profile
Summary: oscap report - false positives for gnome message-banner-text using 'stig-rhel...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: scap-security-guide
Version: 7.2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Lieskovsky
QA Contact: Marek Haicman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-18 16:20 UTC by Blair Aitken
Modified: 2016-08-11 13:14 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-10 16:00:30 UTC


Attachments (Terms of Use)
screenshot of report showing error (deleted)
2016-07-18 16:20 UTC, Blair Aitken
no flags Details
Set the GNOME3 Login Warning Banner Text steps (deleted)
2016-08-10 17:44 UTC, Jan Lieskovsky
no flags Details
Tailoring file that was used for to scan just "Set the GNOME3 Login Warning Banner Text" rule (deleted)
2016-08-10 17:47 UTC, Jan Lieskovsky
no flags Details

Description Blair Aitken 2016-07-18 16:20:15 UTC
Created attachment 1181176 [details]
screenshot of report showing error

Description of problem:
When using openscap with 'stig-rhel7-server-upstream' profile, running a report shows issues with rule ID 'dconf_gnome_login_banner_text' 

(screenshot is attached: gnome3banner.png)

this specific notification is a false positive. It states to set a lock file at /etc/dconf/db/gdm.d/locks/01-my-locks as well as to place a banner message inside the file /etc/dcong/gdm.d/01-banner-message

After proper changes are made, this alert persists.
================================================================ 

Version-Release number of selected component (if applicable):

RHEL 7.2
openscap-1.2.5-3.el7.x86_64
openscap-scanner-1.2.5-3.el7.x86_64
openscap-utils-1.2.5-3.el7.x86_64

How reproducible:

With packages listed above, and profile 'stig-rhel7-server-upstream', run a command like:

 # oscap xccdf eval --profile stig-rhel7-server-upstream --oval-results --report /home/dv1/report.html --results /home/dv1/results.xml --cpe /usr/share/xml/scap/ssg/content/ssg-rhel7-cpe-dictionary.xml /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml

Actual results:

Reports issues with gnome-3-banner text and lock file

Expected results:

After configuration changes have been made, we would expect a report to come back clean.

Comment 4 "Linux" Dan White 2016-08-01 14:40:34 UTC
Hitting the same problem using ssg-rhel7-ds.xml as well as ssg-rhel7-xccdf.xml

When I opened it up with scap-workbench, I got this:

10:30:12 | info     | scap-workbench 1.0.2, compiled with Qt 4.8.5, using openscap 1.2.9
10:30:26 | info     | Opened file '/usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml'.
Entity: line 30: parser error : xmlParseEntityRef: no name
I've read & consent to terms in IS user agreem't.
           ^

So I made a local copy and removed the ampersand in two locations, but it still fails.

Comment 5 "Linux" Dan White 2016-08-01 15:42:11 UTC
I think I narrowed it down, but I cannot figure out where to go from here:

Try this command :

oscap oval eval --id oval:ssg:def:407 --results banner_booboo.xml --verbose DEVEL --verbose-log-file banner_booboo_log.txt /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml

At the end is a failed check that appears to be examining the actual banner text content and failing it.

Why ?  No clue and not ashamed to admit it.

Comment 6 Jan Lieskovsky 2016-08-03 11:00:07 UTC
(In reply to d_e_white from comment #4)

Hello,

> Hitting the same problem using ssg-rhel7-ds.xml as well as
> ssg-rhel7-xccdf.xml
> 
> When I opened it up with scap-workbench, I got this:
> 
> 10:30:12 | info     | scap-workbench 1.0.2, compiled with Qt 4.8.5, using
> openscap 1.2.9
> 10:30:26 | info     | Opened file
> '/usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml'.
> Entity: line 30: parser error : xmlParseEntityRef: no name
> I've read & consent to terms in IS user agreem't.
>            ^
> 
> So I made a local copy and removed the ampersand in two locations, but it
> still fails.

This issue is known to scap-workbench upstream as:
  https://fedorahosted.org/scap-workbench/ticket/255
  https://github.com/OpenSCAP/scap-workbench/commit/565e79955d2bfe634724d862757f0986f033271c

and should be corrected in:
  scap-workbench-1.0.3 and scap-workbench-1.1.2 versions.

Can you repeat with those versions, and confirm it has been addressed?

Thank you, Jan

Comment 7 Jan Lieskovsky 2016-08-03 11:10:52 UTC
(In reply to d_e_white from comment #5)

Hello,
  
> I think I narrowed it down, but I cannot figure out where to go from here:
> 
> Try this command :
> 
> oscap oval eval --id oval:ssg:def:407 --results banner_booboo.xml --verbose
> DEVEL --verbose-log-file banner_booboo_log.txt
> /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml
> 
> At the end is a failed check that appears to be examining the actual banner
> text content and failing it.
> 
> Why ?  No clue and not ashamed to admit it.

The reason for the failure being that current SSG content not only requires login GUI banner text to be set, but also requires it's specific form. In other words requires "banner-message-text" directive config file in "/etc/dconf/db/gdm.d/" location to be set exactly to the "dod_default" version of the "login_banner_text" variable:
  https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/stig-rhel7-server-upstream.xml#L11

where the value of "dod_default" selector is defined to be the following string:

https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/xccdf/system/accounts/banners.xml#L26

Will check with SCAP Security Guide upstream if it would be possible to reduce this restriction to requirement if custom banner text is set (instead of requiring exactly DoD version).

Regards, Jan

Comment 8 "Linux" Dan White 2016-08-03 14:25:27 UTC
(In reply to Jan Lieskovsky from comment #7)
> The reason for the failure being that current SSG content not only requires
> login GUI banner text to be set, but also requires it's specific form. In
> other words requires "banner-message-text" directive config file in
> "/etc/dconf/db/gdm.d/" location to be set exactly to the "dod_default"
> version of the "login_banner_text" variable:
>  
> https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/
> profiles/stig-rhel7-server-upstream.xml#L11
> 
> where the value of "dod_default" selector is defined to be the following
> string:
> 
> https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/
> xccdf/system/accounts/banners.xml#L26
> 
> Will check with SCAP Security Guide upstream if it would be possible to
> reduce this restriction to requirement if custom banner text is set (instead
> of requiring exactly DoD version).
> 
> Regards, Jan

I tried setting the banner-message-text in /etc/dconf/db/gdm.d/01-banner-message to the EXACT string defied by "dod_default" and still get a failure.

Following 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/customizing-login-screen.html

Comment 9 "Linux" Dan White 2016-08-03 14:27:27 UTC
(In reply to Jan Lieskovsky from comment #6)
> This issue is known to scap-workbench upstream as:
>   https://fedorahosted.org/scap-workbench/ticket/255
>  
> https://github.com/OpenSCAP/scap-workbench/commit/
> 565e79955d2bfe634724d862757f0986f033271c
> 
> and should be corrected in:
>   scap-workbench-1.0.3 and scap-workbench-1.1.2 versions.
> 
> Can you repeat with those versions, and confirm it has been addressed?
> 
> Thank you, Jan

Sure.  How to I obtain the newer versions ?  Pull in the git commit and build ? or what ?

Comment 10 Martin Preisler 2016-08-03 16:53:42 UTC
(In reply to d_e_white from comment #9)
> (In reply to Jan Lieskovsky from comment #6)
> > This issue is known to scap-workbench upstream as:
> >   https://fedorahosted.org/scap-workbench/ticket/255
> >  
> > https://github.com/OpenSCAP/scap-workbench/commit/
> > 565e79955d2bfe634724d862757f0986f033271c
> > 
> > and should be corrected in:
> >   scap-workbench-1.0.3 and scap-workbench-1.1.2 versions.
> > 
> > Can you repeat with those versions, and confirm it has been addressed?
> > 
> > Thank you, Jan
> 
> Sure.  How to I obtain the newer versions ?  Pull in the git commit and
> build ? or what ?

The entity warning is mostly harmless. If you want to use newer SCAP Workbench that has it fixed, check out our upstream COPR repo for RHEL7:
https://copr.fedorainfracloud.org/coprs/openscapmaint/openscap-latest/

Keep in mind that packages in that COPR repo are not supported by Red Hat.

Comment 11 "Linux" Dan White 2016-08-09 12:18:43 UTC
Working with 

openscap-1.2.10-1.el7.centos.x86_64
openscap-scanner-1.2.10-1.el7.centos.x86_64
openscap-utils-1.2.10-1.el7.centos.x86_64
perl-Pod-Escapes-1.04-286.el7.noarch
scap-security-guide-0.1.30-2.el7.centos.noarch
scap-security-guide-doc-0.1.30-2.el7.centos.noarch
scap-workbench-1.1.2-1.el7.centos.x86_64

Using the command :
oscap oval eval --id oval:ssg-dconf_gnome_login_banner_text:def:1 --results banner_results.xml --verbose DEVEL --verbose-log-file banner_log.txt /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml

banner-message-text in /etc/dconf/db/gdm.d/01-banner-message is still set to the EXACT string defied by "dod_default" defined at line 11541 of /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml

And it still fails

Here are select lines from the log:

I: oscap: Evaluating definition 'oval:ssg-dconf_gnome_login_banner_text:def:1': Enable GUI Warning Banner. [oscap(9572):oscap(7f79cda58840):oval_resultDefinition.c:152:oval_result_definition_eval]
I: oscap:   Evaluating definition 'oval:ssg-package_dconf_installed:def:1': Package dconf Installed. [oscap(9572):oscap(7f79cda58840):oval_resultDefinition.c:152:oval_result_definition_eval]
I: oscap:   Definition 'oval:ssg-package_dconf_installed:def:1' evaluated as true. [oscap(9572):oscap(7f79cda58840):oval_resultDefinition.c:163:oval_result_definition_eval]
I: oscap:   Evaluating definition 'oval:ssg-enable_dconf_user_profile:def:1': Implement Local DB for DConf User Profile. [oscap(9572):oscap(7f79cda58840):oval_resultDefinition.c:152:oval_result_definition_eval]
I: oscap:   Definition 'oval:ssg-enable_dconf_user_profile:def:1' evaluated as true. [oscap(9572):oscap(7f79cda58840):oval_resultDefinition.c:163:oval_result_definition_eval]
I: oscap:   Evaluating textfilecontent54 test 'oval:ssg-test_prevent_user_banner_change:tst:1': GUI banner cannot be changed by user. [oscap(9572):oscap(7f79cda58840):oval_resultTest.c:1048:oval_result_test_eval]
I: oscap:   Test 'oval:ssg-test_prevent_user_banner_change:tst:1' evaluated as true. [oscap(9572):oscap(7f79cda58840):oval_resultTest.c:1067:oval_result_test_eval]
I: oscap:   Evaluating textfilecontent54 test 'oval:ssg-test_gdm_login_banner_text_setting:tst:1': login banner text is correctly set. [oscap(9572):oscap(7f79cda58840):oval_resultTest.c:1048:oval_result_test_eval]
I: oscap:     State 'oval:ssg-state_gdm_login_banner_text_setting:ste:1' references external_variable 'oval:ssg-login_banner_text:var:1'. [oscap(9572):oscap(7f79cda58840):oval_probe.c:372:oval_probe_query_var_ref]
I: oscap:     Test 'oval:ssg-test_gdm_login_banner_text_setting:tst:1' requires that every object defined by 'oval:ssg-obj_gdm_login_banner_text_setting:obj:1' exists on the system. [oscap(9572):oscap(7f79cda58840):oval_resultTest.c:807:_oval_result_test_evaluate_items]
I: oscap:     1 objects defined by 'oval:ssg-obj_gdm_login_banner_text_setting:obj:1' exist on the system. [oscap(9572):oscap(7f79cda58840):oval_resultTest.c:825:_oval_result_test_evaluate_items]
I: oscap:     All items matching object 'oval:ssg-obj_gdm_login_banner_text_setting:obj:1' were collected. (flag=complete) [oscap(9572):oscap(7f79cda58840):oval_resultTest.c:870:_oval_result_test_evaluate_items]
I: oscap:     In test 'oval:ssg-test_gdm_login_banner_text_setting:tst:1' all of the collected items must satisfy these states: 'oval:ssg-state_gdm_login_banner_text_setting:ste:1'. [oscap(9572):oscap(7f79cda58840):oval_resultTest.c:634:eval_check_state]
I: oscap:     Item '1095833' compared to state 'oval:ssg-state_gdm_login_banner_text_setting:ste:1' with result error. [oscap(9572):oscap(7f79cda58840):oval_resultTest.c:591:eval_item]
I: oscap:   Test 'oval:ssg-test_gdm_login_banner_text_setting:tst:1' evaluated as error. [oscap(9572):oscap(7f79cda58840):oval_resultTest.c:1067:oval_result_test_eval]
I: oscap: Definition 'oval:ssg-dconf_gnome_login_banner_text:def:1' evaluated as error. [oscap(9572):oscap(7f79cda58840):oval_resultDefinition.c:163:oval_result_definition_eval]

Comment 13 Jan Lieskovsky 2016-08-10 15:43:29 UTC
(In reply to d_e_white from comment #8)

Hello,

  thank you for the clarification.

> (In reply to Jan Lieskovsky from comment #7)
> > The reason for the failure being that current SSG content not only requires
> > login GUI banner text to be set, but also requires it's specific form. In
> > other words requires "banner-message-text" directive config file in
> > "/etc/dconf/db/gdm.d/" location to be set exactly to the "dod_default"
> > version of the "login_banner_text" variable:
> >  
> > https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/
> > profiles/stig-rhel7-server-upstream.xml#L11
> > 
> > where the value of "dod_default" selector is defined to be the following
> > string:
> > 
> > https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/
> > xccdf/system/accounts/banners.xml#L26
> > 
> > Will check with SCAP Security Guide upstream if it would be possible to
> > reduce this restriction to requirement if custom banner text is set (instead
> > of requiring exactly DoD version).
> > 
> > Regards, Jan
> 
> I tried setting the banner-message-text in
> /etc/dconf/db/gdm.d/01-banner-message to the EXACT string defied by
> "dod_default" and still get a failure.
> 
> Following 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/
> html/Desktop_Migration_and_Administration_Guide/customizing-login-screen.html

Please don't use the above guidance to configure the system. Though it's universal, it doesn't necessarily recommend to apply all the settings, the scanner is comparing / checking against, when scanning the system against this rules' requirement.

To meet the SSG policy requirement, the system needs to be configured using the steps as outlined in "Enable GNOME3 Login Warning Banner" rule in the prose section of the RHEL-7 policy:
  http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-stig-rhel7-server-gui-upstream.html

Once the system is configured using those steps, the check should pass.

HTH,
Jan

Comment 14 Jan Lieskovsky 2016-08-10 16:00:30 UTC
The requirement of this bug (ability to specify custom banner instead of the required 'dod_default' form) has been consulted with SCAP Security Guide upstream.

The corresponding discussion is here:
  https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org/thread/3WFGXNCRRE7KLW2ZXR4BLVWQO62XOVRC/#3WFGXNCRRE7KLW2ZXR4BLVWQO62XOVRC

The current conclusion being:
"This is actually expected and desired behavior to meet DoD policy. See the Requirement and Vulnerability Discussion of RHEL-07-010030. IMO, as some auditors literally read the banner to verify the policy and to satisfy RHEL-07-010030, we shouldn't change it to only check if a banner is configured."

The RHEL-07-010030 reads as follows (http://rhel7stig.readthedocs.io/en/latest/medium.html#rhel-07-010030-the-operating-system-must-display-the-standard-mandatory-dod-notice-and-consent-banner-before-granting-local-or-remote-access-to-the-system-via-a-graphical-user-logon):

<quote>
RHEL-07-010030 - The operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting local or remote access to the system via a graphical user logon.
Severity

Medium
Description

Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.nnSystem use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.nnThe banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters:nn”You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.nnBy using this IS (which includes any device attached to this IS), you consent to the following conditions:nn-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.nn-At any time, the USG may inspect and seize data stored on this IS.nn-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.nn-This IS includes security measures (e.g., authentication and access controls) to protect USG interests–not for your personal benefit or privacy.nn-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.”nnUse the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner:nn”I’ve read consent to terms in IS user agreem’t.”nnSatisfies: SRG-OS-000023-GPOS-00006, SRG-OS-000024-GPOS-00007, SRG-OS-000228-GPOS-00088
Check

Verify the operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the operating system via a graphical user logon.

Note: If the system does not have GNOME installed, this requirement is Not Applicable.

Check to see if the operating system displays a banner at the logon screen with the following command:

# grep banner-message-enable /etc/dconf/db/local.d/* banner-message-enable=true

If banner-message-enable is set to false or is missing, this is a finding.
Additional Data

    Documentable: false
    False Negatives: None
    False Positives: None
    IA Controls: None
    Mitigation Control: None
    Mitigations: None
    Potential Impacts: None
    Responsibility: None
    Security Override Guidance: None
    Third Party Tools: None
    Control Correlation Identifiers: CCI-000048


</quote>

Since there isn't a way how a SCAP Security Guide check could determine, if the underlying system (target of evaluation) is used in DoD environment, or not, it is not possible to use custom banner for systems utilized outside of DoD environment.

If despite of the above the customer wants to apply custom GUI login banner, they are advised to modify the value of the 'dod_default' selector of the "login_banner_text" value:
  https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/xccdf/system/accounts/banners.xml#L26

as documented in figure "Figure 8. Set minimum password length to 14" of the "Customize the Selected Profile (optional)" section of the SCAP Workbench manual:
  http://static.open-scap.org/scap-workbench-1.1/#_customize_the_selected_profile_optional

In the manual the modification of the value of 'minimum_password_lenght' variable is demonstrated. Similar steps would be performed to change the value of the 'dod_default' selector of the 'login_banner_text' value to reach the custom GUI banner requirement.

Comment 15 "Linux" Dan White 2016-08-10 16:11:38 UTC
(In reply to Jan Lieskovsky from comment #14)
> 
> Check to see if the operating system displays a banner at the logon screen
> with the following command:
> 
> # grep banner-message-enable /etc/dconf/db/local.d/*
> banner-message-enable=true
> 

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/customizing-login-screen.html

This page says to put it in /etc/dconf/db/gdm.d/

Comment 16 "Linux" Dan White 2016-08-10 16:22:16 UTC
And http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-stig-rhel7-server-gui-upstream.html

says : 

Enable GNOME3 Login Warning Banner

To enable displaying a login warning banner in the GNOME Display Manager's login screen, the banner-message-enable setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/gdm.d directory and locked in /etc/dconf/db/gdm.d/locks directory to prevent user modification. After the settings have been set, run dconf update. To display a banner, this setting must be enabled, and the user must be prevented from making changes. The banner text must also be set.

Comment 17 Jan Lieskovsky 2016-08-10 16:40:25 UTC
(In reply to d_e_white from comment #16)
> And
> http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-stig-rhel7-server-gui-
> upstream.html
> 
> says : 
> 
> Enable GNOME3 Login Warning Banner
> 
> To enable displaying a login warning banner in the GNOME Display Manager's
> login screen, the banner-message-enable setting must be set under an
> appropriate configuration file(s) in the /etc/dconf/db/gdm.d directory and
> locked in /etc/dconf/db/gdm.d/locks directory to prevent user modification.
> After the settings have been set, run dconf update. To display a banner,
> this setting must be enabled, and the user must be prevented from making
> changes. The banner text must also be set.

Thanks. Did I got it right the recommendation does not mention the need to set the text to 'dod_default' value?

Is that the problem? Or did I overlook something?

Comment 18 "Linux" Dan White 2016-08-10 16:41:52 UTC
The problem is that the test fails on (I think) the actual banner content

Comment 20 "Linux" Dan White 2016-08-10 17:10:22 UTC
The remediation for /etc/issue that follows this section works with no problem, but the Gnome3 "banner-message-text" stuff stubbornly does not work

Comment 21 Jan Lieskovsky 2016-08-10 17:42:58 UTC
(In reply to d_e_white from comment #18)
> The problem is that the test fails on (I think) the actual banner content

Please see the steps below (will attach them in the form of text file too for more straightforward review):

[root@localhost ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.2 (Maipo)
[root@localhost ~]# rpm -q scap-security-guide
scap-security-guide-0.1.25-3.el7.noarch

Modify the original RHEL-7 benchmark to check only "Set the GNOME3 Login Warning Banner Text" rule:

[root@localhost ~]# cat /root/set_the_gnome3_warning_banner_text_tailoring.txt 
<?xml version="1.0" encoding="UTF-8"?>
<cdf-11-tailoring:Tailoring xmlns:cdf-11-tailoring="http://open-scap.org/page/Xccdf-1.1-tailoring" xmlns:xccdf="http://checklists.nist.gov/xccdf/1.1" id="xccdf_scap-workbench_tailoring_default">
  <cdf-11-tailoring:benchmark href="ssg-rhel7-xccdf.xml"/>
  <cdf-11-tailoring:version time="2016-08-10T18:59:24">1</cdf-11-tailoring:version>
  <xccdf:Profile id="stig-rhel7-server-upstream_tailored" extends="stig-rhel7-server-upstream">
    <xccdf:title xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en-US" override="true">Pre-release Draft STIG for Red Hat Enterprise Linux 7 Server [TAILORED]</xccdf:title>
    <xccdf:description xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en-US" override="true">This profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO.</xccdf:description>
    <xccdf:select idref="partition_for_var_log" selected="false"/>
    <xccdf:select idref="partition_for_var_log_audit" selected="false"/>
    <xccdf:select idref="encrypt_partitions" selected="false"/>
    <xccdf:select idref="ensure_redhat_gpgkey_installed" selected="false"/>
    <xccdf:select idref="ensure_gpgcheck_globally_activated" selected="false"/>
    <xccdf:select idref="ensure_gpgcheck_never_disabled" selected="false"/>
    <xccdf:select idref="security_patches_up_to_date" selected="false"/>
    <xccdf:select idref="service_autofs_disabled" selected="false"/>
    <xccdf:select idref="accounts_minimum_age_login_defs" selected="false"/>
    <xccdf:select idref="accounts_maximum_age_login_defs" selected="false"/>
    <xccdf:select idref="account_temp_expire_date" selected="false"/>
    <xccdf:select idref="accounts_password_pam_dcredit" selected="false"/>
    <xccdf:select idref="accounts_password_pam_minlen" selected="false"/>
    <xccdf:select idref="accounts_password_pam_ucredit" selected="false"/>
    <xccdf:select idref="accounts_password_pam_ocredit" selected="false"/>
    <xccdf:select idref="accounts_password_pam_lcredit" selected="false"/>
    <xccdf:select idref="accounts_password_pam_difok" selected="false"/>
    <xccdf:select idref="accounts_passwords_pam_faillock_deny" selected="false"/>
    <xccdf:select idref="accounts_passwords_pam_faillock_interval" selected="false"/>
    <xccdf:select idref="accounts_password_pam_unix_remember" selected="false"/>
    <xccdf:select idref="banner_etc_issue" selected="false"/>
    <xccdf:select idref="dconf_gnome_banner_enabled" selected="false"/>
    <xccdf:select idref="package_rsyslog_installed" selected="false"/>
    <xccdf:select idref="service_rsyslog_enabled" selected="false"/>
    <xccdf:select idref="audit_rules_time_adjtimex" selected="false"/>
    <xccdf:select idref="audit_rules_time_settimeofday" selected="false"/>
    <xccdf:select idref="audit_rules_time_stime" selected="false"/>
    <xccdf:select idref="audit_rules_time_clock_settime" selected="false"/>
    <xccdf:select idref="audit_rules_time_watch_localtime" selected="false"/>
    <xccdf:select idref="audit_rules_usergroup_modification" selected="false"/>
    <xccdf:select idref="audit_rules_networkconfig_modification" selected="false"/>
    <xccdf:select idref="audit_rules_mac_modification" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_chmod" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_chown" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_fchmod" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_fchmodat" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_fchown" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_fchownat" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_fremovexattr" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_fsetxattr" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_lchown" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_lremovexattr" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_lsetxattr" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_removexattr" selected="false"/>
    <xccdf:select idref="audit_rules_dac_modification_setxattr" selected="false"/>
    <xccdf:select idref="audit_rules_unsuccessful_file_modification" selected="false"/>
    <xccdf:select idref="audit_rules_privileged_commands" selected="false"/>
    <xccdf:select idref="audit_rules_media_export" selected="false"/>
    <xccdf:select idref="audit_rules_file_deletion_events" selected="false"/>
    <xccdf:select idref="audit_rules_sysadmin_actions" selected="false"/>
    <xccdf:select idref="audit_rules_kernel_module_loading" selected="false"/>
    <xccdf:select idref="service_abrtd_disabled" selected="false"/>
    <xccdf:select idref="service_ntpdate_disabled" selected="false"/>
    <xccdf:select idref="service_oddjobd_disabled" selected="false"/>
    <xccdf:select idref="service_qpidd_disabled" selected="false"/>
    <xccdf:select idref="service_rdisc_disabled" selected="false"/>
    <xccdf:select idref="service_atd_disabled" selected="false"/>
    <xccdf:select idref="sshd_enable_warning_banner" selected="false"/>
    <xccdf:select idref="ftp_present_banner" selected="false"/>
    <xccdf:select idref="dconf_gnome_login_banner_text" selected="true"/>
  </xccdf:Profile>
</cdf-11-tailoring:Tailoring>
[root@localhost ~]# rpm -q openscap
openscap-1.2.9-5.el7_2.x86_64

Perform initial scan (should fail):

[root@localhost ~]# oscap xccdf eval --profile stig-rhel7-server-upstream_tailored --tailoring-file /root/set_the_gnome3_warning_banner_text_tailoring.txt /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml 
Title   Set the GNOME3 Login Warning Banner Text
Rule    dconf_gnome_login_banner_text
Ident   CCE-26892-0
Result  fail

Configure the system (set the lock file and expected form of login banner):

[root@localhost ~]# echo '/org/gnome/login-screen/banner-message-text' > /etc/dconf/db/gdm.d/locks/login-banner-locks

root@localhost ~]# cat /etc/dconf/db/gdm.d/login-banner
banner-message-text='You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.  -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls)  to protect USG interests -- not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.'

Perform scan again after system settings:

[root@localhost ~]# oscap xccdf eval --profile stig-rhel7-server-upstream_tailored --tailoring-file /root/set_the_gnome3_warning_banner_text_tailoring.txt /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml
Title   Set the GNOME3 Login Warning Banner Text
Rule    dconf_gnome_login_banner_text
Ident   CCE-26892-0
Result  pass

Comment 22 Jan Lieskovsky 2016-08-10 17:44:43 UTC
Created attachment 1189772 [details]
Set the GNOME3 Login Warning Banner Text steps

Comment 23 Jan Lieskovsky 2016-08-10 17:47:43 UTC
Created attachment 1189776 [details]
Tailoring file that was used for to scan just "Set the GNOME3 Login Warning Banner Text" rule

Comment 25 "Linux" Dan White 2016-08-11 11:17:51 UTC
I think I found part of the problem at my end: 

If I run a complete scan, like this: 

oscap xccdf eval --profile stig-rhel7-server-upstream --oval-results --report report.html --results results.xml /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml

I get a "pass" for GNOME3 Login Warning Banner Text

Using a test specific command, like 

oscap oval eval --id oval:ssg:def:407 --results banner_booboo.xml --verbose DEVEL --verbose-log-file banner_booboo_log.txt /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml

The test fails.

I believe it is because the exact text string  it is looking for is set by the value of the "--profile" option.  I found I could NOT set that option in the second form of the command

Comment 26 Jan Lieskovsky 2016-08-11 13:14:17 UTC
(In reply to d_e_white from comment #25)
> I think I found part of the problem at my end: 
> 
> If I run a complete scan, like this: 
> 
> oscap xccdf eval --profile stig-rhel7-server-upstream --oval-results
> --report report.html --results results.xml
> /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml
> 
> I get a "pass" for GNOME3 Login Warning Banner Text

Yes. Because in the case of "stig-rhel7-server-upstream" profile the value of "login_banner_text" variable is refined (read customized) to "dod_default" selector value:
  https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/stig-rhel7-server-gui-upstream.xml#L8

(the current code in upstream's master has now the stig profile split into three profiles, but IIRC in 0.1.25 version the profile has had this setting. Can be verified by searching for 'refine-value' and 'dod_default' strings directly in the /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml file)

> 
> Using a test specific command, like 
> 
> oscap oval eval --id oval:ssg:def:407 --results banner_booboo.xml --verbose
> DEVEL --verbose-log-file banner_booboo_log.txt
> /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml
> 
> The test fails.
> 
> I believe it is because the exact text string  it is looking for is set by
> the value of the "--profile" option.

That's correct the profile can redefine values of some variables. The STIG one redefines the value of 'login_banner_text' to 'dod_default' selector.

In the case there isn't a profile specified (direct OVAL check is evaluated), I would say the following XCCDF:Value options apply:
  https://scap.nist.gov/specifications/xccdf/xccdf_element_dictionary.html#valueType

to be more exact, the following:

"At any time an <xccdf:Value> has one active (simple or complex) value. If a selector value has been provided under <xccdf:Profile> selection or tailoring then the active <xccdf:value>/<xccdf:complex-value> is the one with a matching @selector. If there is no provided selector or if the provided selector does not match the @selector attribute of any <xccdf:value> or <xccdf:complex-value>, the active <xccdf:value>/<xccdf:complex-value> is the one with an empty or absent @selector or, failing that, the first <xccdf:value> or <xccdf:complex-value> in the XML. When an <xccdf:Value> is exported or used in text substitution, it is the currently active <xccdf:value> or <xccdf:complex-value> that is actually used."

Given there's no <xccdf:value> with empty or absent @selector in 'login_banner_text' definition:
  https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/xccdf/system/accounts/banners.xml#L20

I would say (according to the above, without testing) the first value, thus the one specified by "usgcb_default" selector is expected to be configured on the system.


>  I found I could NOT set that option in
> the second form of the command

See above. Without profile different order applies when identifying active value for the <xccdf:value>. I would expect in the latter case, the "usgcb_default" one to be expected as setting.

HTH, Jan


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