On Wed, Aug 3, 2016 at 6:40 AM, Steve Grubb <sgrubb@redhat.com> wrote:
On Wednesday, August 3, 2016 7:17:15 AM EDT Jan Lieskovsky wrote:
> Hello,
>
>   please see downstream report:
>   [1] https://bugzilla.redhat.com/show_bug.cgi?id=1357620
>
> In short the reason for the failure here not being the system in question
> (target of evaluation) wouldn't meet the required setting, but the only
> difference is the form of banner text used (instead of 'dod_default'
>
> https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/xc
> cdf/system/accounts/banners.xml#L26
>
> the customers are using custom text for the login banner).
>
> Can we modify the 'dconf_gnome_login_banner_text.xml' OVAL not to be
> that restrictive? In other words, allow also other custom banners to be
> set on the target of evaluation under assumption, other requirements
> were already satisfied?
>
> Basically the change would be instead of exact banner text string match
> against 'dod_default' selector value of 'login_banner_text' variable,
> the new version would check if desired login banner text isn't empty
> string.

I think this is reasonable. When we had meetings to draft the first USGCB
content, it was mentioned that different groups had different legal counsel and
thus the possibility of different verbiage. But they wanted a default for
everyone because it was a general requirement.

-Steve

> Thoughts?

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.
What we could do is add an empty variable called "default" or "custom" under login_banner_text in the banners.xml XCCDF, and for those needing a custom banner
that does not have to meet a particular policy, point them to adding/modify the custom banner text in scap-workbench.

Gabe