Date: Mon, 10 May 2004 17:32:35 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Tom Rhodes <trhodes@FreeBSD.org> Cc: FreeBSD-doc@FreeBSD.org Subject: Re: [REVIEW REQUEST]: New chapter on MAC (draft) Message-ID: <Pine.NEB.3.96L.1040510172624.98179D-100000@fledge.watson.org> In-Reply-To: <20040510172607.354ecb0a@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040510172624.98179D-100000>