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

[Robert Watson]

On Mon, 10 May 2004, Tom Rhodes wrote:

> > Suggestion: drop the coverage of mac_test, mac_none, and mac_stub.  Those
> > exist much more for the benefit of the developer than the user.  You can
> > mention they exist but I don't think I'd do much more than that, as they
> > add noise without any real pay-off for most end users.
> 
> Perhaps I can discuss them in the troubleshooting section or in a
> simple/basic section.  :) 

Well, the problem is that they're really not intended for use by end
users, and wouldn't really serve much purpose for an end-user.
Specifically:

mac_stub	Yes, it really does nothing.  It's intended as a no-op
		policy to facilitate benchmarking relative to other policies.  An
		end-user could use it for benchmarking, I suppose.

mac_none	Yes, this one does nothing else, only it does it more
		comprehensively by implementing all the entry-points with
		no-ops.  Again, maybe benchmarking, but not really.

mac_test	Internal consistency checks of the MAC Framework.  I think
		you could argue this might benefit users by allowing them to have
		a redundant set of consistency checks and fail-stop
		behavior.  However, many policies implement at least a
		subset of these checks, and the checks only apply under
		INVARIANTS.  This module is really intended for people
		developing or shipping systems with modifications to test that the
		system works right, as well as to help use track changes in
		FreeBSD and make sure the MAC Framework is working
		properly.  From the user perspective under normal
		operation, though, it does nothing also.

I've actually wondered if we should ship these separate from the src tree,
but they're very helpful in ongoing development so I've left them in.

> > I think you might want to add a section that summarizes what it is MAC
> > policies can do (labeling, etc).  You can use that to segway to a
> > discussion of MAC policy trade-offs, including the increased cost of
> > administration, multilabel file systems, etc.
> 
> We can do this at the beginning, right where it belongs.  :) 

Sounds good.

> > BTW, feel free to send this thread (or related threads) to the trustedbsd
> > list.  I suspect there might be a greater audience there when it comes to 
> > reviewing technical content, but could be mistaken.
> 
> I was planning to do this; I just wanted some initial review from the
> doc team first. 
> 
> I'll try to merge your suggestions in tonight or tomorrow before I pack
> for BSDCan; thanks! 

Sounds good!.

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