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"'
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
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
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@redhat.com] Sent: Thursday, August 15, 2013 4:03 PM To: scap-security-guide@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
scap-security-guide@lists.fedorahosted.org