Can we change the banner text requirement for "dconf_gnome_login_banner_text" to allow custom banner text? (RH BZ#1357620)
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/xcc...
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.
Thoughts?
Thank you && Regards, Jan -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
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?
Thank you && Regards, Jan
Jan iankko Lieskovsky / Red Hat Security Technologies Team
SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah osted.org https://github.com/OpenSCAP/scap-security-guide/
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
scap-security-guide@lists.fedorahosted.org
-
Gabe Alford -
Jan Lieskovsky -
Steve Grubb