No subject


Fri Jul 27 01:24:50 UTC 2012


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


--------------030709060307050503050107
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><small><tt>Shawn, I was at the airport and rushed my response
          below.  Thanks for your thoughts/comments below.</tt></small></p>
    <p><small><tt>When talking with Jeff and David last week (and prior)
        </tt></small><tt><small>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.</small></tt></p>
    <p><tt><small>Perhaps we all need to have a call, and clearly
          define/determine what we are doing.  Fr</small></tt><small><tt>om
          what I gathered talking to Jeff Thursday, a</tt><tt>s 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.<br>
        </tt></small></p>
    <p><small><tt>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.</tt></small><br>
    </p>
    <tt><small>Of course, I'm willing to accommodate any requests that
        we all agree on -- we just have to define them ahead of time.<br>
        <br>
        Thanks.<br>
        <br>
        MM</small><br>
      <br>
    </tt>
    <blockquote cite="mid:5068FA7A.9060400 at redhat.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      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.<br>
      <br>
      Thanks,<br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 09/30/2012 01:46 PM, Shawn Wells
        wrote:<br>
      </div>
      <blockquote cite="mid:50688568.6000104 at redhat.com" type="cite">
        <meta content="text/html; charset=UTF-8"
          http-equiv="Content-Type">
        <div class="moz-cite-prefix">On 9/30/12 12:34 AM, Michael J.
          McConachie wrote:<br>
        </div>
        <blockquote
          cite="mid:20120930043406.GA5620 at mobile.dude.localdomain"
          type="cite"><br>
          <fieldset class="mimeAttachmentHeader"><legend
              class="mimeAttachmentHeaderName">0005-Test-Tags-added-for-input-system-selinux.xml.patch</legend></fieldset>
          <br>
          <div class="moz-text-plain" wrap="true" graphical-quote="true"
            style="font-family: -moz-fixed; font-size: 12px;"
            lang="x-western">
            <pre wrap="">From 5f7d2293a2df184a27fe5516e31597005ee1e188 Mon Sep 17 00:00:00 2001
From: Michael McConachie <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:michael at redhat.com">&lt;michael at redhat.com&gt;</a>
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.
 &lt;ident cce="3977-6" /&gt;
 &lt;oval id="selinux_bootloader_notdisabled" /&gt;
 &lt;ref nist="AC-3, CM-6" /&gt;
+&lt;tested by="MM" on="20120929"/&gt;
 &lt;/Rule&gt;</pre>
          </div>
        </blockquote>
        <br>
        nack<br>
        <br>
        OCIL text should show a trivial command (likely grep?) for this,
        vs giving general instructions on the need to human review a fil<br>
      </blockquote>
    </blockquote>
    <blockquote cite="mid:5068FA7A.9060400 at redhat.com" type="cite">
      <blockquote cite="mid:50688568.6000104 at redhat.com" type="cite"> <br>
        <blockquote
          cite="mid:20120930043406.GA5620 at mobile.dude.localdomain"
          type="cite">
          <div class="moz-text-plain" wrap="true" graphical-quote="true"
            style="font-family: -moz-fixed; font-size: 12px;"
            lang="x-western">
            <pre wrap=""> &lt;Rule id="set_selinux_state"&gt;
@@ -124,6 +125,7 @@ privileges.
 &lt;ident cce="3999-0" /&gt;
 &lt;oval id="selinux_mode" value="var_selinux_state_name"/&gt;
 &lt;ref nist="CM-6, CM-7" disa="22"/&gt;
+&lt;tested by="MM" on="20120929"/&gt;
 &lt;/Rule&gt;</pre>
          </div>
        </blockquote>
        nack<br>
        <br>
        selinux should be set to enabled in grub config as well, similar
        to how we put audit=1 <br>
        <br>
        <blockquote
          cite="mid:20120930043406.GA5620 at mobile.dude.localdomain"
          type="cite">
          <div class="moz-text-plain" wrap="true" graphical-quote="true"
            style="font-family: -moz-fixed; font-size: 12px;"
            lang="x-western">
            <pre wrap=""> &lt;Rule id="set_selinux_policy"&gt;
@@ -149,6 +151,7 @@ targeted for exploitation, such as network services or system services.
 &lt;ident cce="3624-4" /&gt;
 &lt;oval id="selinux_policytype" value="var_selinux_policy_name"/&gt;
 &lt;ref nist="CM-6, CM-7" /&gt;
+&lt;tested by="MM" on="20120929"/&gt;
 &lt;/Rule&gt;
 &lt;/Group&gt;</pre>
          </div>
        </blockquote>
        nack<br>
        <br>
        as written, if a system is configured as MLS it will be a (very
        false) finding. OCIL text should reflect SELINUXTYPE value can
        be <i>either</i> targeted or mls<br>
        <br>
        <blockquote
          cite="mid:20120930043406.GA5620 at mobile.dude.localdomain"
          type="cite">
          <div class="moz-text-plain" wrap="true" graphical-quote="true"
            style="font-family: -moz-fixed; font-size: 12px;"
            lang="x-western">
            <pre wrap=""> 
@@ -243,6 +246,7 @@ If a device file is not labeled, then misconfiguration is likely.
 &lt;ident cce="14991-4" /&gt;
 &lt;oval id="selinux_all_devicefiles_labeled" /&gt;
 &lt;ref nist="CM-6, CM-7" /&gt;
+&lt;tested by="MM" on="20120929"/&gt;
 &lt;/Rule&gt;
 &lt;/Group&gt;</pre>
          </div>
        </blockquote>
        nack<br>
        - language of description still choppy<br>
        - OCIL command not adequate. Why not use "ls -RZ / | grep
        unlabeled_t"? Or a find -context unlabeled_t?<br>
      </blockquote>
    </blockquote>
    <br>
    Fix Text (Description):<br>
    <br>
    <small><tt>Choppy?</tt><tt><br>
      </tt><tt><br>
      </tt><tt>From the page: "Device files are used for communication
        with important system resources.
        SELinux contexts should exist for these. By checking for </tt><code>unlabeled_t</code><tt>
        file
        contexts, we can determine if the system is optimally
        configured."</tt><tt><br>
      </tt><tt><br>
      </tt><tt>-- 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.)</tt><tt><br>
      </tt><tt><br>
      </tt><tt>Check Text Block:</tt><tt><br>
      </tt></small>
    <pre xmlns=""><small>"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</small></pre>
    <small><tt>
        "It should produce no output in a well-configured system.  If
        unlabeled_t file contexts exist, this is a finding."</tt></small><check-content
      xmlns="http://checklists.nist.gov/xccdf/1.1"><small><tt><br>
        </tt><tt><br>
        </tt><tt>-- 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.  </tt></small><br>
    </check-content>
    <blockquote cite="mid:5068FA7A.9060400 at redhat.com" type="cite">
      <blockquote cite="mid:50688568.6000104 at redhat.com" type="cite"> <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
scap-security-guide mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:scap-security-guide at lists.fedorahosted.org">scap-security-guide at lists.fedorahosted.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
scap-security-guide mailing list
<a class="moz-txt-link-abbreviated" href="mailto:scap-security-guide at lists.fedorahosted.org">scap-security-guide at lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------030709060307050503050107--


More information about the scap-security-guide mailing list