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.
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:
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
nack<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>
selinux should be set to enabled in grub config as well, similar to how we put audit=1
nack<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>
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
nack@@ -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>
- language of description still choppy
- OCIL command not adequate. Why not use "ls -RZ / | grep unlabeled_t"? Or a find -context unlabeled_t?
unlabeled_t
file
contexts, we can determine if the system is optimally
configured.""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."
_______________________________________________ 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