On 02/08/2013 02:12 PM, Brian Millett wrote:
I'm trying to understand (as an example) the following results from an
evaluation on a rhel6.3 box using the stig-rhel6-server profile.  And I
apologize if these questions are answered in a FAQ somewhere.

If they are I'm unaware of it.

1)
Ensure Log Files Are Owned By Appropriate Group 	unknown
Ensure System Log Files Have Correct Permissions 	unknown

Both of these end up at an OVAL <unknown_test>. This is a manifestation of OVAL inadequacy.

2)
All GIDs referenced in /etc/passwd must be defined in /etc/group notchecked 
Ensure All Accounts on the System Have Unique Names              notchecked

These lack OVAL checks, and were likely thus not checked (I don't have that <Profile> in front of me at the moment; either they were not selected in the <Profile>, or were, and the evaluation engine chose to skip them due to the lack of an OVAL check).

I understand that the "notchecked" is because there is not an oval test
defined and the "unknown" is a specific "I don't know", as in the
rsyslog_files_groupownership.xml:

  <ind:unknown_test check="all"
  comment="use extended content to evaluated this test"
  id="test_20155" version="1" />

So I've been reading the oval language definitions and I cannot see how to
address the "unknown" tests which require parsing a file to get parts out of
it (rsyslog wants defined log paths).  

That is because there is nothing to see. OVAL is inadequate to the task.

Q) How does one go about writing a test
that takes the result from evaluating a script?  What is the "extended
content"??

I think this can be done using evaluation based on shell scripting in OpenSCAP. I have not yet looked at this, so cannot confirm whether it has been implemented. I know it is technically feasible.

I am unsure what "extended content" meant. Some <Rule>s have OCIL checks defined, though these cannot be posed to the ToE. I don't think they are the "extended content". I suspect "extended content" presumes something other and better than OVAL.

Q) Are the "notchecked" tests because the check is too vague? Or just not
written yet?

It is because OVAL is inadequate, and will remain durably so. It is anathema to the purveyors of OVAL to include a test based on arbitrary POSIX shell scripting.

Any documents I should be reading?

Other than taking a look at OpenSCAP to see if/where they implemented shell-based checking, no.

Avoid NIST SP 800-126 rev 2 as long as you possibly can, and even then prefer the prior revision. §4.5.2 covers mapping of OVAL results to XCCDF results.

Of course, when something cannot be expressed in OVAL, other means must be sought — means other than strict SCAP.

It would be a serious waste of time to attempt such evaluations in OVAL (as they are impossible), time better spent devising a concise shell-based script that could be evaluated using an alternate check engine.