Various False Positives?

Maura Dailey maura at eclipse.ncsc.mil
Wed Aug 28 21:59:49 UTC 2013


The variable for space_left_action is supposed to be set in the XCCDF 
Profile. The variable name is var_auditd_space_left_action and the stig 
profile just doesn't set it, so it defaults to email. I read the STIG, 
and the STIG agrees, it should be email (RHEL-06-000005).

- Maura Dailey

On 08/28/2013 05:05 PM, Robert Sanders wrote:
> For extra sauce, the 'space_left_action' check is the one that went 
> from PASS to FAIL, and the current value went from 'SYSLOG' to 'email'.
>
> ------------------------------------------------------------------------
> *From:* Robert Sanders
> *Sent:* Wednesday, August 28, 2013 4:52 PM
> *To:* scap-security-guide at lists.fedorahosted.org
> *Subject:* RE: Various False Positives?
>
> Maura,
>   I just pulled the latest git stuff down and made it all, zipped up 
> all the 'ssg-' files from the output directory and dropped that on the 
> SCC3.1 GA scanner.  A stock box had 6 passes and 5 failures out of 
> total of 388 items. After locking it down with SB I went to 5 passes 
> and 6 failures (yep - wrong way) out of 388.  Operator error on making 
> the packages ?
>
>   Couple of interesting questions on the results (after scan):
>
>
>
>   Set default bash umask (ditto for csh and default umask)
>     Examing the indicated files shows there are two places where the 
> umask could be set, one for 002 and one for 022, with the UID of the 
> caller determining which is used.  The scanner is catching the first 
> instance.
>
>   Configure Auditd for space_left and admin_space_left:
>     In both cases I inspected the /etc/audit/auditd.conf file and 
> verify that the required line is present according to the prose. I do 
> notice that the list of appropriate actions appears to be a single 
> 'word' set to be:
>
>    ignoresyslogemailexecsuspendsinglehalt
>
> Not sure what is going on under the hood to know if these are being 
> glommed together for the prose but kept separate for the OVAL checks 
> or not.
>
> I need to try and rerun with the SCC rc6 beta, but may not have time 
> today...
>
> -Rob
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
> *From:* scap-security-guide-bounces at lists.fedorahosted.org 
> [scap-security-guide-bounces at lists.fedorahosted.org] on behalf of 
> Maura Dailey [maura at eclipse.ncsc.mil]
> *Sent:* Wednesday, August 28, 2013 1:05 PM
> *To:* scap-security-guide at lists.fedorahosted.org
> *Subject:* Re: Various False Positives?
>
> 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
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
>
>
> _______________________________________________
> 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/23abafd1/attachment.html>


More information about the scap-security-guide mailing list