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.