I think the RPM is just really out of date.
Hmmm, I'll look into the umask thing, but I was under the assumption
that if one failed, the whole file should fail, so that's probably the
reasoning behind never looking for a second umask value. Note that the
prose guide section for each umask setting makes no attempt to
distinguish between multiple places to change umask settings.
I checked and noticed that admin_space_left and admin_space_left_action
don't show up at all in the STIG. I also noticed that the title for the
prose section describing admin_space_left_action is wrong in the SSG. I
wonder if the variable name is also wrong and the check is looking for
the wrong thing? I will check this tomorrow.
I don't know where "ignoresyslogemailexecsuspendsinglehalt" is coming
from. Grepping through the entire SSG reveals nothing. When I get in
tomorrow, I'll try to track down what's happening (maybe regex gone wrong?).
If you open up the XCCDF in a text editor, you'll notice that Rules will
sometimes contain <check> tags. These check tags have nearly unreadable
ids, BUT you will find them in ssg-rhel6-oval.xml with the same names
and can get a human readable ref_id that will point you to the correct
file in RHEL6/input/checks in the git repo.
- Maura Dailey
On 08/28/2013 04:52 PM, Robert Sanders wrote:
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
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:
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
I need to try and rerun with the SCC rc6 beta, but may not have time
[scap-security-guide-bounces(a)lists.fedorahosted.org] on behalf of
Maura Dailey [maura(a)eclipse.ncsc.mil]
*Sent:* Wednesday, August 28, 2013 1:05 PM
*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
> 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
> 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?
> Mind on a Mission <http://leamhall.blogspot.com/>
> scap-security-guide mailing list
scap-security-guide mailing list