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(a)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(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide