[REVIEW REQUEST]: New chapter on MAC (draft)

Simon L. Nielsen simon at FreeBSD.org
Mon May 10 23:18:54 UTC 2004


On 2004.05.10 16:51:53 -0400, Tom Rhodes wrote:
> Hey FreeBSD-doc,
> 
> I've written a new chapter for the handbook on implementing the
> MAC features in 5.X.  It includes configuration, testing, module
> description that augments the section we already have, and shows
> examples of the policies.

In general: great! :-).  I have been looking at the MAC label policies a
few times without really understanding how they were suposed to work.
It has helped a lot to read this chapter!

> I'm not worried about whitespace right now, only correctness in the
> information presented, markup, and wording.

I have some comments below.  I will try to go over it again tomorrow in
more detail to give more comments.

BTW, there are some <screen> parts that are indented, which shouldn't be
(not mentioned below since it is more or less whitespace).

<!--
     The FreeBSD Documentation Project
     $Pittgoth: projects/scripts/chapter.sgml,v 1.10 2004/05/10 20:42:14 darklogik Exp $
     $FreeBSD$
-->

   <para>With security requirements on a rise throughout much of the
     the world, the demand for a more secure environment has
     increased.  It is from this demand that the TrustedBSD project
     was founded with nothing more than security in mind.  The
     TrustedBSD project has aimed at developing userland utilities and kernel
     interfaces, based on the <acronym>POSIX</acronym>.1e standard, and merging it

AFAIR POSIX.1e is not really a POSIX standard, but was an draft standard
which was never completed (that's my memory anyway, I could very well be
wrong).

Also, POSIX is also trademark, so &posix;.

 <sect1 id="mac-initial">
[snip]

   <para>After the kernel has been installed, the
     <option>multilabel</option> option may need to be enabled

I think it would be good to explain briefly what labels is before you
start to explain their use.

 <sect1 id="mac-portacl">
  <title>The MAC portacl Module</title>

I have been playing with this policy and I'm actually using it now, so I
have fairly good idea how it works. The section contains several
inaccuracies...  I think the simplest thing is for me to try to rewrite
parts of the section to be more accurate.  I hope get that done some
time tomorrow.

  <sect1 id="mac-labelingpolicies">
    <title>MAC Policies with Labeling Features</title>

    <para>The next few sections will discuss <acronym>MAC</acronym>
      policies which support the labeling features.</para>

    <warning>
      <para>Please take notice that the improper use of the
        following information may cause loss of access to the system;
        aggravation of users; inability to access the features
        provided by <application>XFree86</application>; and should not

s/XFree86/&xfree86;/

        be believed to completely secure a system.  The
        <acronym>MAC</acronym> framework only promises to augment
        security but without a good security policy and regulatory
        security checks, believing the system is totally secure would
        be irrational if not completely inappropriate.</para>
    </warning>

    <para>From hereon this chapter will focus on the features
      of &man.mac.biba.4;, &man.mac.lomac.4;,
      &man.mac.partition.4;, and &man.mac.mls.4;.</para>

    <para>For these policies to work correctly several
      preparations must be made.</para>

    <sect2 id="mac-prep">
      <title>Preparation for Labeling Policies</title>

      <para>The following changes should be made to the
        <filename>/etc/login.conf</filename> file:</para>

      <itemizedlist>
        <listitem>
          <para>An <username>insecure</username> class should be
            added.  The login class of <username>insecure</username>
            is not required and just used as an example here; different
            configurations may use another class name.</para>
        </listitem>

        <listitem>
          <para>The class of <username>insecure</username> should have
            the following settings and definitions.</para>

          <programlisting>insecure:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\
:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
:manpath=/usr/share/man /usr/local/man:\
:nologin=/usr/sbin/nologin:\
:cputime=1h30m:\
:datasize=8M:\
:vmemoryuse=100M:\
:stacksize=2M:\
:memorylocked=4M:\
:memoryuse=8M:\
:filesize=8M:\
:coredumpsize=8M:\
:openfiles=24:\
:maxproc=32:\
:priority=0:\
:requirehome:\
:passwordtime=91d:\
:umask=022:\
:ignoretime@:\
:label=partition/13,mls/5:</programlisting>

          <para>The <command>cap_mkdb</command> must be run on

Manual page entity for cap_mkdb (&man.cap.mkdb.8; AFAIR)

            <filename>login.conf</filename> before any of the

&man.login.conf.5;

            users can be switched over to the new class.</para>
        </listitem>

        <listitem>
          <para>Set labels for <command>ifconfig</command>
            interfaces:</para>

          <screen>&prompt.root; <userinput>ifconfig bge0 maclabel 'biba/high(low-high)'</userinput></screen>

          <para>This will set the biba label to high for all incoming
            and outgoing packets.</para>
        </listitem>

        <listitem>
          <para>Ensure that all partitions which <acronym>MAC</acronym>
            labeling will be implemented on support the
            <option>multilabel</option>.  We must do this as many of
            the examples here contain different labels for testing
            purposes.  Review the output from
            <command>mount</command> command as a precautionary
            measure.</para>
        </listitem>

        <listitem>
          <para>Switch any users who will have the higher security
            mechanisms enforced over to the new user class.  A quick
            run of <command>pw</command> or <command>vipw</command>

&man.pw.8; and &man.vipw.8;

            should do the trick.</para>
        </listitem>
      </itemizedlist>
    </sect2>
  </sect1>

  <sect1 id="mac-partition">
    <title>The MAC partition Module</title>

    <indexterm>
    <primary>MAC Process Partition Policy</primary>
    </indexterm>
    <para>Module name: <filename>mac_partition.ko</filename></para>
    <para>Kernel option: <literal>MAC_PARTITION</literal></para>
    <para>Boot option: <literal>mac_partition_load="YES"</literal></para>

    <para>The &man.mac.partition.4; policy will drop processes into
      specific <quote>partitions</quote> based on their
      <acronym>MAC</acronym> label.  Think of it as a special
      type of &man.jail.8;, though that is hardly a worthy
      comparison.</para>

    <para>This is one module that should be added to the
      <filename>loader.conf</filename> file so that it loads

&man.loader.conf.5;

      and enables the policy during the boot process.</para>

  <sect1 id="mac-mls">
    <title>The MAC Multi-Level Security Module</title>

    <indexterm>
    <primary>MAC Multi-Level Security Policy</primary>
    </indexterm>
    <para>Module name: <filename>mac_mls.ko</filename></para>
    <para>Kernel option: <literal>MAC_MLS</literal></para>
    <para>Boot option: <literal>mac_mls_load="YES"</literal></para>

    <para>The &man.mac.mls.4; policy controls access between subjects
      and objects in the system by enforcing a strict information
      flow policy.</para>

I think it would be good to have subjects and objects should defined
here (or rather, before using them in the above paragraph).

    <para>In <acronym>MLS</acronym> environments, a
      <quote>clearance</quote> level is set in each subject or objects
      label, along with compartments.  Since these clearance or
      sensibility levels can reach numbers greater than six thousand;
      it would be a daunting task for any system administrator to
      thoroughly configure each subject or object.  Thankfully, three
      <quote>instant</quote> labels are already included in this
      policy.</para>

    <para>These labels are <option>mls/low</option>,
      <option>mls/equal</option> and <option>mls/high</option>.
      Since these labels are described in depth in the manual page,
      they will only get a brief description here:</para>

    <itemizedlist>
      <listitem>
        <para>The <option>mls/low</option> label contains a low
          configuration which permits it to be dominated by all other
          objects.  Anything labeled with <option>mls/low</option>
          will have a low clearance level and not permitted to access
          information of a higher level.  In addition, this label will
          prevent objects of a higher clearance level from writing or
          passing information on to them.</para>
      </listitem>

      <listitem>
        <para>The <option>mls/equal</option> label should be
          placed on objects considered to be exempt from the
          policy.</para>
      </listitem>

      <listitem>
        <para>The <option>mls/high</option> is the highest level
          of clearance possible.  Objects assigned this label will
          hold dominance over all over objects in the system; however,
          they will not permit the leaking of information to objects
          of a lower class.</para>
      </listitem>
    </itemizedlist>

    <para>The following <command>sysctl</command> tunables are
      available for the configuration of special services and
      interfaces:</para>

    <itemizedlist>
      <listitem>
        <para><option>security.mac.mls.enabled</option> is used to
          enable/disable the <acronym>MLS</acronym> policy.</para>
      </listitem>

      <listitem>
        <para><option>security.mac.mls.ptys_equal</option> will label
          all &man.pty.4; devices as <option>mls/equal</option> during
          Creation.</para>

s/Creation/creation/

      </listitem>

[snip]

      <sect2>
        <title>Set All Users to Insecure</title>

        <para>All user accounts that are not <username>root</username>
          or system users should can now be set to insecure.  The
          following <command>sh</command> script should do the
          trick:</para>

        <screen>&prompt.root; <userinput>for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \</userinput>
          <userinput>/etc/passwd`; do pw usermod $x -L insecure; done;</userinput></screen>

        <para>The <command>cap_mkdb</command> command will need to be
          run on <filename>/etc/master.passwd</filename> after this
          change.</para>
      </sect2>

      <sect2>
        <title>Complete the Configuration</title>

        <para>A contexts file should now be created; the following
          example was taken from Robert Watson's example policy and
          should be placed in
          <filename>/etc/policy.contexts</filename>.</para>

        <programlisting># This is the default BIBA/MLS policy for this system.

.*                              biba/high,mls/high
/sbin/dhclient                  biba/high(low),mls/high(low)
/dev(/.*)?                      biba/equal,mls/equal
# This is not an exhaustive list of all "privileged" devices.
/dev/mdctl                      biba/high,mls/high
/dev/pci                        biba/high,mls/high
/dev/k?mem                      biba/high,mls/high
/dev/io                         biba/high,mls/high
/dev/agp.*                      biba/high,mls/high
(/var)?/tmp(/.*)?               biba/equal,mls/equal
/tmp/\.X11-unix                 biba/high(equal),mls/high(equal)
/tmp/\.X11-unix/.*              biba/equal,mls/equal
/proc(/.*)?                     biba/equal,mls/equal
/mnt.*                          biba/low,mls/low
(/usr)?/home                    biba/high(low),mls/high(low)
(/usr)?/home/.*                 biba/low,mls/low
/var/mail(/.*)?                 biba/low,mls/low
/var/spool/mqueue(/.*)?         biba/low,mls/low
(/mnt)?/cdrom(/.*)?             biba/high,mls/high
(/usr)?/home/(ftp|samba)(/.*)?  biba/high,mls/high
/var/log/sendmail\.st           biba/low,mls/low
/var/run/utmp                   biba/equal,mls/equal
/var/log/(lastlog|wtmp)         biba/equal,mls/equal</programlisting>

simon: If possible I think it would be nice to descript (briefly) what
this sample policy is suposed to do.

  <sect1 id="mac-troubleshoot">

[snip]

   <itemizedlist>
     <listitem>
       <para>After establishing a secure environment with
         <acronym>MAC</acronym>, I am no longer able to start
         <application>XFree86</application>!</para>

s/XFree86/&xfree86;/

     </listitem>
   </itemizedlist>

   <para>This could be caused by the <acronym>MAC</acronym>
     <option>partition</option> policy or by a mislabel in one of
     the <acronym>MAC</acronym> labeling policies.  To debug, try
     the following:</para>

   <procedure>
     <step>
       <para>Check the error message; if the user in the
         <username>insecure</username> class then the
         <option>partition</option> policy may be the culprit.  Try
         setting the users class back to the
         <username>default</username> class, rebuild the database
         with the <command>cap_mkdb</command> command.  If this
         does not alleviate the problem, go to step two.</para>
     </step>

     <step>
       <para>Double check the label policies.  Ensure that the
         policies are set correctly for the user in question, the
         <application>XFree86</application> application, and

s/XFree86/&xfree86;/

         the <filename role="directory">/dev</filename>
         entries.</para>
     </step>

     <step>
       <para>If neither of these resolve the problem, send the
         error message and a description of your environment to
         the TrustedBSD discussion list or the &os; Questions

I think there should be some kind of reference where to find the
TrustedBSD mailing list.

s/&os; Questions mailing list/&a.questions;/;

         mailing list.</para>


     </step>
   </procedure>
  </sect1>

-- 
Simon L. Nielsen
FreeBSD Documentation Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-doc/attachments/20040511/00041a39/attachment.sig>


More information about the freebsd-doc mailing list