On Wed, Aug 3, 2016 at 6:40 AM, Steve Grubb <[email protected]> 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
--
SCAP Security Guide mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
https://github.com/OpenSCAP/scap-security-guide/

Reply via email to