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

[Robert Watson]

On Tue, 11 May 2004, Tom Rhodes wrote:

> On Mon, 10 May 2004 17:49:18 -0400
> Tom Rhodes <trhodes at FreeBSD.org> wrote:
> 
> Updated with comments from this list and a few in private.

A few comments:

(1) The glossary seems a little out of place -- some terms are for the MAC
    Framework, others are from policies.  I'd suggest making it into its
    own section/sub-section.  That way you lead straight into a discussion
    of the framework and policies, and you can refer to the glossary
    elsewhere.

(2) Per our discussion at BSDCan, you should have a section of file system
    labels and the multilabel flag, probably in the same place the
    current discussion is. I would not advise users turn on multilabel
    unless their specific configuration requires it.  You might want to
    preceed this section with a section on what labels are.  Chris's
    mac_label(7) man page might make a good starting point.

(3) You might consider adding a similar section on network interfaces and
    labels after that, and a section on process labels.  This might be a
    good place to discuss assigning labels to users with login.conf.

(4) The tunables/sysctls probably aren't all that relevant to most users,
    and probably shouldn't be used except during development and
    debugging.  This is because they can have unintended consequences for
    some modules, controlling more than just access control checks (i.e.,
    for lomac).  It's worth noting somewhere that MAC policies also have
    their own configuration parameters, typically under the tree
    security.mac.<policyname>. 

(5) If you add a label sub-section earlier, the discussion of labels in
    23.3 Module Configuration can become a simple sentence referencing
    that section. 

(6) In section 23.4.1 Examples for the ugidfw module, the example uses a
    user named "user".  I'm not sure the documentation explains that.

(7) The warning in "23.7 MAC Policies with Labeling Features" applies to
    the other policies also.  You can quite disable a system using
    mac_bsdextended, for example.

(8) In the same section, "support the labeling feature" might be better
    expressed as "use labels".

(9) Section 23.7.1 needs some more broad refinement.  The label example in
    23.7.1 "Preparation for Labeling Policies" appears to set up a
    demonstration label set, but uses the word "Should".  That seems
    misleading and may cause odd results.  Make sure to document that this
    is a sample configuration entry to document the syntax -- users will
    never want to use these specific settings in practice.  Also, the high
    level summary of the bulleted list has to do with login.conf, but the
    ifconfig line definitely doesn't.  Much of this can probably go above
    in the discussion of labels.  I'm not sure what the final bullet
    refers to. 

(10) A lot of the text here appears to be duplicated from 23.7 and other
     sections.  I'm not clear all of it belongs here.

(11) In 23.13, you refer to the problem in setting the multilabel flag on
     /.  This problem is a result of either incorrect documentation or
     incorrect following of the documentation.  I'd suggest rephrasing the
     problem description to reflect that, or it leaves the impression the
     software does not operate consistently.  It does operate
     consistently, just not conveniently... :-)

(12) In 23.13, the formatting is a bit funky.  The bulleted sub-headings
     are indented more than the text, and to the same depth as numbered
     lists.  I'd suggest making them headers.

(13) I would suggest adding a section that talks a bit about selecting
     policies to support security goals.  I would not suggest recommending
     the user turn on MLS and Biba to get a more secure system, as the
     process needs to be a bit more complicated than that.  A simple
     example using just Biba to constrain a web server would probably be
     a good starting point.  Or an example placing users in different
     compartments for sandboxing purposes.

Thanks!

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research




To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message