Classification: UNCLASSIFIED Caveats: NONE > Shawn Wells <[email protected]> wrote: > On 2/20/13 12:49 PM, Shaw, Ray V CTR (US) wrote: > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > During the public comment period, should I be sending comments to > DISA > > regarding the benchmark content (which they didn't include in their > > download), or just regarding the prose (e.g. "I would like to see ___ > > as an acceptable setting as well as the stated value of ____")? > > It is a little awkward and confusing. > > Feedback against the DISA RHEL6 STIG prose should be sent to DISA FSO. > They are the publishing authority of the STIG and we don't want to > avoid a situation where FSO is unaware of said feedback (and thus the > feedback doesn't make it into the final STIG). Their EMail address is: > [email protected] > > With that said, the SSG serves as upstream for the RHEL6 STIG content. > If you give us a heads up, we may be able to get it fixed before the > public comment period even ends :) We also track feedback via our > ticketing system, which allows us to correlate any reported findings > with DISA FSO: > https://fedorahosted.org/scap-security-guide/report/3
Thanks. I'll be sure to report anything where I would like to see a change in the actual requirement to the DISA address. As a "for instance" for other cases, the prose for the password_min_age check appears to want this in login.defs: PASS_MIN_DAYS 1 which is fine, and is what we have. But the actual check appears to be looking for a value of "7 or higher", so it fails (using both tools; based on your comments regarding SCC, I won't report anything that fails on SCC but passes with Open SCAP). I'm running into similar issues with the "gconftool-2" type rules, where I've run the indicated commands and they appear to have written to the appropriate places, but the checks are still failing. Should I just report things like that here? [We also have an interesting issue where there is an inspection coming up, and we're not sure whether they're going to use the RHEL5 or RHEL6 draft STIG to evaluate RHEL6 systems. This is a problem, because there are a bunch of rules in them that conflict, e.g. /bin/true vs /bin/false or always,exit vs exit,always; explainable as equivalent and false positives, but makes scans for one or the other look awful. Hopefully the team will let us know shortly.] -- Ray Shaw Contractor, STG Unix support, Army Research Labs Classification: UNCLASSIFIED Caveats: NONE _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
