Hi Shawn, Hi all, ----- Original Message ----- > From: "Shawn Wells" <[email protected]> > To: [email protected] > Sent: Tuesday, July 5, 2016 3:46:44 PM > Subject: Re: [Open-scap] Informational value > > > > On 7/1/16 3:38 AM, Jan Cerny wrote: > > > > Regarding your second question, OpenSCAP >= 1.2.2 can display OVAL results > in the HTML report if you run it with "--oval-results", eg.: > > # oscap xccdf eval --results results.xml --oval-results --report report.html > my_benchmark.xml > > The HTML report will look like in [2]. > > [1] http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf > (page 43) > [2] > https://www.open-scap.org/wp-content/uploads/2015/09/ssg-rhel7-ds-xccdf.report.html > > Can we have the findings showup in the default reports, e.g. those without > --oval-results? Why burden the users with another CLI argument?
The report is generated from both the XCCDF results and OVAL results documents using XSLT templates and transformations. The XSLT just parses the XML document and converts it into a nicely formated document. I think we can have OVAL details by default when report is created. On the other hand, the --oval-results option has a side effect - it generates an OVAL results XML document. Does it matter that there will be always an additional file? Or should we create a temporary file? Could we prefer using ARFs? > > Also, some of the OVAL result summaries are very confusing. Compare "Set Last > Logon/Access Notification" with the various object and type expressions > listed in "Set Deny For Failed Password Attempts".... it's not clear what > all that means. "Last Logon" shows the text of the passing file, whereas > "Failed Password Attempts" lists subexpressions instead. > > Does this depend on how the OVAL rules are written, or OpenSCAP reporting? > Reports would be easier to interpret if we showed the offending text, vs a > "subexpression" value. I agree that it is often confusing. It depends on the way how the OVAL checks are written. These problems are all caused by the fact that the report is created after from the OVAL and XCCDF results documents. We have to follow the SCAP standards in those documents. Adding another information to the report that cannot be represented in OVAL results is a problem. We could "hack" the <message> elements and use them for storing the values for the report. > > E.g.: current report from "failed password attempts": > > > > > Items not found violating Check pam_faillock.so preauth silent present in > /etc/pam.d/system-auth : > Object oval:ssg:obj:870 of type textfilecontent54_object > Behaviors Filepath Pattern Instance > no value /etc/pam.d/system-auth > > [\n][\s]*auth[\s]+required[\s]+pam_faillock\.so[\s]+preauth[\s]+silent[\s]+[^\n]*deny=([0-9]+)[\s]*[^\n]*[\n][\s]*auth[\s]+sufficient[\s]+pam_unix\.so[^\n]*[\n] > 1 State oval:ssg:ste:871 of type textfilecontent54_state > Subexpression > 6 > > > Could be changed to: > > > Items not found violating Check pam_faillock.so preauth silent present in > /etc/pam.d/system-auth : > Object oval:ssg:obj:870 of type textfilecontent54_object > Behaviors Filepath Pattern Instance > no value /etc/pam.d/system-auth > > [\n][\s]*auth[\s]+required[\s]+pam_faillock\.so[\s]+preauth[\s]+silent[\s]+[^\n]*deny=([0-9]+)[\s]*[^\n]*[\n][\s]*auth[\s]+sufficient[\s]+pam_unix\.so[^\n]*[\n] > 1 State of /etc/pam.d/system-auth > Subexpression > FAIL: No lines match regex in /etc/pam.d/system-auth Great idea. Implementing such a thing in XSLT will be very challenging :-) but your suggestion would greatly improve the user experience. > > _______________________________________________ > Open-scap-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/open-scap-list Best Regards Jan Černý Security Technologies | Red Hat, Inc. _______________________________________________ Open-scap-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/open-scap-list
