Maura,
I'm using the yum repos for my latest download also instead of git. I can corroborate several of the false positives on my RHEL6 box after locking things down with Security Blanket, and manually reviewing the failures. There are several that need additional scrutiny. I used SCC 3.1 GA to run the checks as it seems to give me more insight into the results than oscap does (any suggestions on increasing the who/what/where/how/why logging w/o having to rebuild oscap from source appreciated).
I'd just reverted the VM where I'd done the SCC scan so I don't have the results in front of me, but from memory :
57/58/59 - SCC was showing the line, including the correct value, then complaining that the value didn't match what it was looking for. Wonder if this is a case of not handling the leading '-' incorrectly?
73 - I know the RHEL5 STIG had an issue with whitespace at one point that I'd gotten around
206-211 I don't have telnet on my box either, but I think it may be treating the failure of finding /etc/xinetd.d/telnet as not finding 'disabled' in that file
240 I had this also, but we set the file to point to /etc/issue rather than /etc/issue.net. The *contents* of both files are the same (the correct banner). Perhaps the check should be checking the contents of whatever banner is being used rather than just the setting references the right file name?
-Rob
From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of leam hall [leamhall@gmail.com]
Sent: Wednesday, August 28, 2013 2:02 PM
To: scap-security-guide@lists.fedorahosted.org
Subject: Re: Various False Positives?
Hey Maura!
I'm using the openscap-utils rpm and the content from the Fedorahosted zip file.
On Wed, Aug 28, 2013 at 1:05 PM, Maura Dailey <maura@eclipse.ncsc.mil> wrote:
Stupid question, but what are you running against exactly? The RPM or the latest git checkout? I want to make sure that if I run this, I'm seeing the same results, and I've made a lot of changes to OVAL checks in the git repository in the past few weeks. I'm going to run through your list, comparing it against the OVAL checks.On 08/28/2013 12:04 PM, leam hall wrote:
Hey all,
Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG.
Fix text definitely implies this. It's not the only service that implies it's allowed in certain environments, but then proceeds to only accept a value of disabled.
9 rhnsd can be on if configured to Satellite server or similar
For the previous 3, I'd like to see the pam_cracklib.so line so I can troubleshoot.
57 ucredit
58 ocredit
59 lcredit
Going back to my many many OVAL check updates, I'd like to see your exact /etc/issue so I can debug what went wrong. If it's an exact copy of the text from the STIG, I'll work off that.73 /etc/issue
Do you mean it's disabled on your system, but the OVAL checks are saying it isn't?98 No ipv6 installed
?99 "
The STIG actually says that stime is not necessary, which is kind of a strange wording, but the suggested line in the fix text prose is correct, at least. So far as OVAL checks go, I haven't gotten to testing audit checks yet. Maybe this is broken. I'll check it out once I've deciphered the OVAL check.
165 adjtimex
167 settimeofday
169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall
Haven't tested audit checks yet...
171 clock_settime
184-196, 200 chmod, chown, etc...
These are both automated checks. Unless the package name is wrong, I don't know why they'd give false positives.
206-211 No telnet installed or turned on
The OVAL check was definitely working on my system when I last tested it.240 /etc/ssh/sshd_config Banner
Working on testing this one now...
271 If there are no removable partitions this is not a finding.
Agreed, the GNOME checks need to be rewritten to have extended definitions to exclude machines that don't have X installed.
278 If the file permissions are more restrictive then it is not a finding.
324 No X running
?326 "
This is DEFINITELY a bug. The check section is actually pointing to a different check. The actual check for this rule was never written.
346 Finding reported on umask 022
No OVAL check exists in SSG.
348 No vsftp installed, thus no file.
This one isn't in the SSG at all.506 "hushlogin"
This one isn't in the SSG at all.507 PrintLastLog
- Maura Dailey
Am I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings?
Leam
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
--
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide