Question on 'Verify File Hashes with RPM', and results in general

Robert Sanders rsanders at TrustedCS.com
Thu Aug 15 20:18:44 UTC 2013


Steve,
  Thank you for the clarification on the grep/awk.  I didn't think command syntax made sense to me unless there was either a hidden transmogrification of the command or an addendum to grep that I missed somewhere...

-Rob

________________________________________
From: Steve Grubb [sgrubb at redhat.com]
Sent: Thursday, August 15, 2013 4:03 PM
To: scap-security-guide at lists.fedorahosted.org
Cc: Robert Sanders
Subject: Re: Question on 'Verify File Hashes with RPM', and results in general

On Thursday, August 15, 2013 07:07:54 PM Robert Sanders wrote:
>  Ok, I'm stumped now.  I'm using the latest SSG content (downloaded today)
> on a RHEL6.4 64bit VM.  On this box I loaded the latest SPAWAR release
> candidate as well as Security Blanket.  Ran the scan, and this module
> passed, but it failed in Security Blanket.  Poking through the SSG content
> I ran the command as indicated in the description manually and it *failed*.
>  So looking in the check-content section for this rule I see 3 entries -
> one for the CCE reference
>   one for a oval definition
>   one for an ocil-transitional
>
>   If I drill down through the oval definition it *looks* like there's an
> pattern match for only looking at things with a 'bin' as part of the path,
> which would skip the things that appeared to bork. Looked at the
> ocil-transitional definition I see a command  using grep like I've *never*
> seen before (note the && was escaped in the xccdf file)
>
> description command ->   rpm -Va | grep '^..5'
> check-content(ocil-trans) command -> rpm -Va | grep '$1 ~ /..5/ && $2 !=  "c"'

That ocil 'grep' should be an 'awk'. Grep doesn't parse into $1, $2 fields,
awk does. So, if any regex is based off of this mistake...it will surely not
work. I can't answer the rest of the questions, but awk is definitely what
appears to be in order for the ocil check.

-Steve


> So...
> question 1 - which command is actually being run?  I'm assuming the one from
> the oval, as the ocil one doesn't make any sense to me unless the command
> is being mangled  before execution, or someone snuck something into grep
> when I wasn't looking...
>
> Question 2 - Is there any way to have oscap spit out a log file of the
> commands/checks actually being run, so see why things may or may not have
> triggered a fail?
>
> Question 3 - If the command being run is actually from the oval, with the
> pathname pattern match, why doesn't the description detail the same
> exception?  I've had this complaint with the RHEL5 STIG as well where there
> have been a few line items where the description says one thing and the
> actual check is doing some extra stuff.
>
> -Rob


More information about the scap-security-guide mailing list