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.
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.
9 rhnsd can be on if configured to Satellite server or similar
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.
57 ucredit
58 ocredit
59 lcredit
For the previous 3, I'd like to see the pam_cracklib.so line so I
can
troubleshoot.
73 /etc/issue
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.
98 No ipv6 installed
Do you mean it's disabled on your
system, but the OVAL checks are saying
it isn't?
99 "
?
165 adjtimex
167 settimeofday
169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall
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.
171 clock_settime
184-196, 200 chmod, chown, etc...
Haven't tested audit checks yet...
206-211 No telnet installed or turned on
These are both
automated checks. Unless the package name is wrong, I
don't know why they'd give false positives.
240 /etc/ssh/sshd_config Banner
The OVAL check was definitely
working on my system when I last tested it.
271 If there are no removable partitions this is not a finding.
Working on testing this one now...
278 If the file permissions are more restrictive then it is not a
finding.
324 No X running
Agreed, the GNOME checks need to be rewritten to have extended
definitions to exclude machines that don't have X installed.
326 "
?
346 Finding reported on umask 022
This is DEFINITELY a bug.
The check section is actually pointing to a
different check. The actual check for this rule was never written.
348 No vsftp installed, thus no file.
No OVAL check exists in
SSG.
506 "hushlogin"
This one isn't in the SSG at
all.
507 PrintLastLog
This one isn't in the SSG at all.
- Maura Dailey
Am I confused in thinking a system in run level 3 should net need to
worry about X/Gnome findings?
Leam
--
Mind on a Mission <
http://leamhall.blogspot.com/>
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide