Shawn, I was at the airport and rushed my response below.  Thanks for your thoughts/comments below.

When talking with Jeff and David last week (and prior) it was described to me was that the final intent of the "check text" field will be to serve as a generic spot check field with info for a more manual way to double check/verify SCAP's work after the fact.  It isn't an exhaustive list of exacting manual steps to harden a box if followed from top to bottom.  [The actual OCIL work behind the scenes (as you already know) is a different story.] I asked some of the same questions, and had similar comments as yours at the time.

Perhaps we all need to have a call, and clearly define/determine what we are doing.  From what I gathered talking to Jeff Thursday, as I find ones that fail (or are too obscure) to pass a yes/no "does it work?" test, I will mark them as bad so that they are show up as red, instead of green.  Then when the list is completed, they'll all be revisited, edited, and retested until in a green state.

Essentially, the individual acks/nacks to each patch that has test tags in the subj line can be misleading/misinterpreted -- because the actual "patch" is an informational comment to inform the community that testing is under-weigh, and that test tags are being added one by one.

Of course, I'm willing to accommodate any requests that we all agree on -- we just have to define them ahead of time.

Thanks.

MM


Thanks for the input.  To clarify, I only ran the test (and it passed) didn't write that rule.  I'd suggest you post the change, and push it since you've got a bead on it, then I can retest it.  Appreciate the info/input/catch.

Thanks,


On 09/30/2012 01:46 PM, Shawn Wells wrote:
On 9/30/12 12:34 AM, Michael J. McConachie wrote:

0005-Test-Tags-added-for-input-system-selinux.xml.patch

From 5f7d2293a2df184a27fe5516e31597005ee1e188 Mon Sep 17 00:00:00 2001
From: Michael McConachie <michael@redhat.com>
Date: Sun, 30 Sep 2012 00:31:14 -0400
Subject: [PATCH 5/6] Test Tags added for input/system/selinux.xml

---
 RHEL6/input/system/selinux.xml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/RHEL6/input/system/selinux.xml b/RHEL6/input/system/selinux.xml
index 286f324..23f7875 100644
--- a/RHEL6/input/system/selinux.xml
+++ b/RHEL6/input/system/selinux.xml
@@ -102,6 +102,7 @@ the chances that it will remain off during system operation.
 <ident cce="3977-6" />
 <oval id="selinux_bootloader_notdisabled" />
 <ref nist="AC-3, CM-6" />
+<tested by="MM" on="20120929"/>
 </Rule>

nack

OCIL text should show a trivial command (likely grep?) for this, vs giving general instructions on the need to human review a fil

 <Rule id="set_selinux_state">
@@ -124,6 +125,7 @@ privileges.
 <ident cce="3999-0" />
 <oval id="selinux_mode" value="var_selinux_state_name"/>
 <ref nist="CM-6, CM-7" disa="22"/>
+<tested by="MM" on="20120929"/>
 </Rule>
nack

selinux should be set to enabled in grub config as well, similar to how we put audit=1

 <Rule id="set_selinux_policy">
@@ -149,6 +151,7 @@ targeted for exploitation, such as network services or system services.
 <ident cce="3624-4" />
 <oval id="selinux_policytype" value="var_selinux_policy_name"/>
 <ref nist="CM-6, CM-7" />
+<tested by="MM" on="20120929"/>
 </Rule>
 </Group>
nack

as written, if a system is configured as MLS it will be a (very false) finding. OCIL text should reflect SELINUXTYPE value can be either targeted or mls

 
@@ -243,6 +246,7 @@ If a device file is not labeled, then misconfiguration is likely.
 <ident cce="14991-4" />
 <oval id="selinux_all_devicefiles_labeled" />
 <ref nist="CM-6, CM-7" />
+<tested by="MM" on="20120929"/>
 </Rule>
 </Group>
nack
- language of description still choppy
- OCIL command not adequate. Why not use "ls -RZ / | grep unlabeled_t"? Or a find -context unlabeled_t?

Fix Text (Description):

Choppy?

From the page: "Device files are used for communication with important system resources. SELinux contexts should exist for these. By checking for unlabeled_t file contexts, we can determine if the system is optimally configured."

-- We can add more to it by saying that unlabeled_t contexts aren't optimal for SELinux enabled systems for reasons a,b,c,d although, that isn't the intent of this column/field.  (I'm not sure who wrote that originally but it reads fine IMO for what we're trying to accomplish at this time.  Quick, and to the point.)

Check Text Block:
"To check for unlabeled device files, run the following command in the directory that you want to check the SELinux contexts:

# ls -Z | grep unlabeled_t
"It should produce no output in a well-configured system.  If unlabeled_t file contexts exist, this is a finding."

-- Again, not sure where that originated from , but the way I read it is as a file by file, and or directory by directory basis.  Not a recursive search. 



_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide



_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide