<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Maura,<br>
&nbsp; I'm using the yum repos for my latest download also instead of git.&nbsp; I can corroborate several of the false positives on my RHEL6 box after locking things down with Security Blanket, and manually reviewing the failures.&nbsp; There are several that need additional
 scrutiny.&nbsp; 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).<br>
&nbsp; 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 :<br>
<br>
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.&nbsp; Wonder if this is a case of not handling the leading '-' incorrectly?<br>
<br>
73 - I know the RHEL5 STIG had an issue with whitespace at one point that I'd gotten around<br>
<br>
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<br>
<br>
240 I had this also, but we set the file to point to /etc/issue rather than /etc/issue.net.&nbsp; The *contents* of both files are the same (the correct banner).&nbsp; Perhaps the check should be checking the contents of whatever banner is being used rather than just
 the setting references the right file name?<br>
<br>
<br>
-Rob<br>
<br>
<div style="font-family: Times New Roman; color: rgb(0, 0, 0); font-size: 16px;">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF106483"><font color="#000000" face="Tahoma" size="2"><b>From:</b> scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of leam hall [leamhall@gmail.com]<br>
<b>Sent:</b> Wednesday, August 28, 2013 2:02 PM<br>
<b>To:</b> scap-security-guide@lists.fedorahosted.org<br>
<b>Subject:</b> Re: Various False Positives?<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">Hey Maura!<br>
<br>
I'm using the openscap-utils rpm and the content from the Fedorahosted zip file.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Aug 28, 2013 at 1:05 PM, Maura Dailey <span dir="ltr">
&lt;<a href="mailto:maura@eclipse.ncsc.mil" target="_blank">maura@eclipse.ncsc.mil</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor="#FFFFFF">
<div class="im">
<div>On 08/28/2013 12:04 PM, leam hall wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hey all,<br>
<br>
</div>
<div>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 &quot;RHEL-06-000&quot;. These are all marked as fail but the server meets the STIG.<br>
</div>
</div>
</blockquote>
</div>
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.
<div class="im"><br>
<blockquote type="cite">
<div dir="ltr">
<div>&nbsp; 9&nbsp;&nbsp; rhnsd can be on if configured to Satellite server or similar<br>
</div>
</div>
</blockquote>
</div>
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.
<div class="im"><br>
<blockquote type="cite">
<div dir="ltr">
<div>&nbsp;57&nbsp;&nbsp; ucredit <br>
</div>
<div>&nbsp;58&nbsp;&nbsp; ocredit<br>
</div>
<div>&nbsp;59&nbsp;&nbsp; lcredit<br>
</div>
</div>
</blockquote>
</div>
For the previous 3, I'd like to see the pam_cracklib.so line so I can troubleshoot.<br>
<blockquote type="cite">
<div dir="ltr">
<div>&nbsp;73&nbsp;&nbsp; /etc/issue<br>
</div>
</div>
</blockquote>
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.<br>
<blockquote type="cite">
<div dir="ltr">
<div>&nbsp;98&nbsp; No ipv6 installed<br>
</div>
</div>
</blockquote>
Do you mean it's disabled on your system, but the OVAL checks are saying it isn't?<br>
<blockquote type="cite">
<div dir="ltr">
<div>&nbsp;99&nbsp; &quot;<br>
</div>
</div>
</blockquote>
?
<div class="im"><br>
<blockquote type="cite">
<div dir="ltr">
<div>165&nbsp; adjtimex<br>
</div>
<div>167&nbsp; settimeofday<br>
</div>
<div>169&nbsp; stime&nbsp; // Also, the STIG is wrong. There is no x86_64 stime syscall<br>
</div>
</div>
</blockquote>
</div>
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.
<div class="im"><br>
<blockquote type="cite">
<div dir="ltr">
<div>171&nbsp; clock_settime<br>
</div>
<div>184-196, 200 chmod, chown, etc...<br>
</div>
</div>
</blockquote>
</div>
Haven't tested audit checks yet...
<div class="im"><br>
<blockquote type="cite">
<div dir="ltr">
<div></div>
<div>206-211&nbsp; No telnet installed or turned on<br>
</div>
</div>
</blockquote>
</div>
These are both automated checks. Unless the package name is wrong, I don't know why they'd give false positives.<br>
<blockquote type="cite">
<div dir="ltr">
<div>240&nbsp; /etc/ssh/sshd_config Banner<br>
</div>
</div>
</blockquote>
The OVAL check was definitely working on my system when I last tested it.
<div class="im"><br>
<blockquote type="cite">
<div dir="ltr">
<div>271&nbsp; If there are no removable partitions this is not a finding.<br>
</div>
</div>
</blockquote>
</div>
Working on testing this one now...
<div class="im"><br>
<blockquote type="cite">
<div dir="ltr">
<div>278&nbsp; If the file permissions are more restrictive then it is not a finding.<br>
</div>
<div>324&nbsp; No X running<br>
</div>
</div>
</blockquote>
</div>
Agreed, the GNOME checks need to be rewritten to have extended definitions to exclude machines that don't have X installed.<br>
<blockquote type="cite">
<div dir="ltr">
<div>326&nbsp;&nbsp; &quot;&nbsp; <br>
</div>
</div>
</blockquote>
?
<div class="im"><br>
<blockquote type="cite">
<div dir="ltr">
<div>346&nbsp; Finding reported on umask 022<br>
</div>
</div>
</blockquote>
</div>
This is DEFINITELY a bug. The check section is actually pointing to a different check. The actual check for this rule was never written.
<div class="im"><br>
<blockquote type="cite">
<div dir="ltr">
<div>348&nbsp; No vsftp installed, thus no file.<br>
</div>
</div>
</blockquote>
</div>
No OVAL check exists in SSG.<br>
<blockquote type="cite">
<div dir="ltr">
<div>506&nbsp; &quot;hushlogin&quot;<br>
</div>
</div>
</blockquote>
This one isn't in the SSG at all.<br>
<blockquote type="cite">
<div dir="ltr">
<div>507&nbsp; PrintLastLog<br>
</div>
</div>
</blockquote>
This one isn't in the SSG at all.<br>
<br>
- Maura Dailey<br>
<br>
<blockquote type="cite">
<div class="im">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
<div>Am I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings?<br>
<br>
</div>
<div>Leam<br>
</div>
<div>
<div><br>
-- <br>
<div><a href="http://leamhall.blogspot.com/" target="_blank">Mind on a Mission</a></div>
</div>
</div>
</div>
<br>
<fieldset target="_blank"></fieldset> <br>
</div>
<pre>_______________________________________________
scap-security-guide mailing list
<a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a>
<a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
scap-security-guide mailing list<br>
<a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a><br>
<a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div><a href="http://leamhall.blogspot.com/" target="_blank">Mind on a Mission</a></div>
</div>
</div>
</div>
</div>
</body>
</html>