Various False Positives?

Maura Dailey maura at eclipse.ncsc.mil
Wed Aug 28 19:58:04 UTC 2013


I'm not the one packaging up the rpm, so I don't know how out of date 
that is. I'd like Leam and you both to test against the git repository 
to see if any of my recent OVAL patches fix any of these problems. That 
will help me prioritize anything that's still broken.

I'll do a full run myself against the git repository in a little bit 
here, but I have some uncommitted changes that might lead to different 
results

Thanks,
- Maura Dailey

On 08/28/2013 02:21 PM, Robert Sanders wrote:
> 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 at lists.fedorahosted.org 
> [scap-security-guide-bounces at lists.fedorahosted.org] on behalf of leam 
> hall [leamhall at gmail.com]
> *Sent:* Wednesday, August 28, 2013 2:02 PM
> *To:* scap-security-guide at 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 at eclipse.ncsc.mil 
> <mailto:maura at eclipse.ncsc.mil>> wrote:
>
>     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 at lists.fedorahosted.org  <mailto:scap-security-guide at lists.fedorahosted.org>
>>     https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
>
>     _______________________________________________
>     scap-security-guide mailing list
>     scap-security-guide at lists.fedorahosted.org
>     <mailto:scap-security-guide at lists.fedorahosted.org>
>     https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
>
>
>
> -- 
> Mind on a Mission <http://leamhall.blogspot.com/>
>
>
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130828/d58ff80a/attachment-0001.html>


More information about the scap-security-guide mailing list