[Open-scap] Need help understanding RHEL STIG findings

[Brian Millett]

On Wed, 30 Jan 2013 16:38:37 +0000
"Snyder, Chris" <Chris_Snyder at sra.com> wrote:

> [First, I'm new to openscap, OVAL,  STIG, XCCDF, etc.  I'm trying to
> comprend it all, but I feel I'm drinking from the firehose right now.  If my
> questions show a severe lack of knowledge on my part, please suggest what I
> should go read next to resolve that.  Thx.]
> 
> I'm trying to understand my findings from applying the latest RHEL5 STIG
> Benchmark against one of my RHEL5 hosts.  The results appear to indicate
> some false positives and I don't know how to determine if that is indeed the
> case or not.  Ultimately, I would love to gain more insight into how to
> determine what tests are being performed by openscap for a given
> STIG/XCCDF/OVAL item or at least how to find out the results of the tests
> being run, i.e. I want to understand WHY openscap is reporting these items
> as failed.
> 
> Limiting this discussion to only one of my supposed false positives, my
> results for the item SV-37347r1_rule, "Result for The root account must be
> the only account having a UID of 0." indicate I've failed.  However, when I
> run 'grep ":0:" /etc/passwd', I get the following:
> 
> #  grep ":0:" /etc/passwd
> root:x:0:0:root:/root:/bin/bash
> sync:x:5:0:sync:/sbin:/dev/null
> shutdown:x:6:0:shutdown:/sbin:/dev/null
> halt:x:7:0:halt:/sbin:/dev/null
> operator:x:11:0:operator:/root:/dev/null
> 
> Only one account has a UID of 0, so I don't know why the report shows I've
> failed this test.  Thus, this is why I'm treating it as a false positive.
> How do I go about debugging this and understanding what openscap/OVAL is
> doing here and why it says I've failed?  Is openscap just running some form
> of grep command against /etc/password or is it much more complex than that?
> Is there some way I can run the test by hand to see the raw output/results?
> 
> Here's what I'm using:
> 
> -          I've downloaded and compiled a copy of openscap 0.9.3 and
> installed it via RPM on my RHEL5 host (BTW, I didn't notice any compilation
> errors)
> 
> -          Latest RHEL5 STIG Benchmark:
> u_redhat_5_v1r2_stig_benchmark_20130125.zip
> 
> I run the following command:
>                 oscap xccdf eval --profile MAC-2_Public --report report.html
> --results results.xml U_RedHat_5_V1R2_STIG_Benchmark-xccdf.xml

Chris, 

I've just recently started doing the same fun exercise.  I'd point out a
couple of project that have helped me.

https://fedorahosted.org/scap-security-guide/  a very nice package that makes
scap a bit easier for RHEL-5 & 6

http://www.g2-inc.com/index.php/innovations/building-scap - for a really good
editor for XCCDF & OVAL documents.

I also use bluefish editor when I have to get down and edit XML files by hand.

So for your problem I'll give you a brain dump that I've used, which I'm sure
the experts will say "you're crazy", but ...

So with that rule,

    <Rule id="SV-37347r1_rule" severity="medium" weight="10.0">
      .....
      <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
        <check-content-ref name="oval:mil.disa.fso.rhel:def:70" href="U_RedHat_5-V1R1_STIG_Benchmark-oval.xml" />
      </check>
    </Rule>

The check is being done by def:70 in the STIG_Benchmark-oval.xml, so that following the references in the 
xml file,

def:70->tst:7000->obj:7701

    <unix-def:file_object id="oval:mil.disa.fso.rhel:obj:7701" version="1" comment="root exec search path directories">
      <unix-def:path var_check="at least one" var_ref="oval:mil.disa.fso.rhel:var:7700" datatype="string" />
      <unix-def:filename datatype="string" xsi:nil="true" />
    </unix-def:file_object>

Which leads you off into root path directories, or into a big WHAT??

So yeah, the oval is messed up.

But that is my observation, and I'm no expert.

Looking forward to the answer to the problem.
-- 
Brian Millett
"Oh, that's cute. A zombie with a gas attack."
           -- [ Garibaldi, "Knives"]