From owner-freebsd-doc@FreeBSD.ORG Mon Nov 22 14:47:28 2004 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E818116A4CE for ; Mon, 22 Nov 2004 14:47:28 +0000 (GMT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85C9843D1D for ; Mon, 22 Nov 2004 14:47:28 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id 083333C8; Mon, 22 Nov 2004 08:47:27 -0600 (CST) Date: Mon, 22 Nov 2004 08:47:27 -0600 From: Tillman Hodgson To: freebsd-doc@freebsd.org Message-ID: <20041122144727.GY61766@seekingfire.com> References: <419E4747.6070001@FreeBSD.org> <419E510B.6020800@elvandar.org> <20041119203338.GF61766@seekingfire.com> <200411200335.56638.max@love2party.net> <20041120030001.GI61766@seekingfire.com> <20041122005112.GA73187@freebsdmall.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041122005112.GA73187@freebsdmall.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/personal/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers X-Tillman-rules: yes he does User-Agent: Mutt/1.5.6i Subject: Re: Proposal regarding security chapter X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 14:47:29 -0000 On Sun, Nov 21, 2004 at 04:51:12PM -0800, Murray Stokely wrote: > On Fri, Nov 19, 2004 at 09:00:01PM -0600, Tillman Hodgson wrote: > > V System Administration -> MAC -> Biba > > V System Administration -> Firewalls -> PF > > V System Administration -> Kerberos5 > > I think you mean 'Security' here. As in a new Security , rather > than two named 'System Administration'. Yes. > > Basically putting all of the security topics on equal footing. This > > highlights the importance of security, makes individual topics easier to > > find (and less "deep" in level), > > Adding a new part and pushing the total chapter count to 30 is going > to remove some of "easier to find" justification. I find that a finely-grained ToC is generally more useful, *especially* in a reference manual. > This would also move content about SSH and MAC away from chapters > about NIS, Unix accounts, other network services, etc. I don't have a problem with that. MAC has its own chapter and there's a proposal to make Firewalls its own chapter. I think that this trend will continue as more detailed documentation is written about the various security topics. As a hypothetical end user looking for Security information, if I look in III System Administration -> Security I'm no longer getting the whole picture. It's become a "Where's Waldo?" adventure :-) > I like the original suggestion best: moving the firewall (and OpenSSH > sections) out of security and into the Network Services . > Network Services is our newest part, and the System Admin part has > twice as many chapters as the Network Services . We should just > continue the work that began this summer of moving the network bits > out of the general System Administration part and into the Network > Services part. That's what it was created for. iI agree with you as far as network services are concerned. However, I think that Security is a different topic than network services (albeit with some overlap). I guess my concern boils down to this: A hypothetical user who wants to learn about security w.r.t FreeBSD *but doesn't yet know the right buzzwords* doesn't have a place to look. They might be able to pick it up by osmosis if they read two of the largest sections of the Handbook, but I don't consider that a good solution. I admit to bit of bias in this area. In another of my aspects I'm a security consultant so I tend to advocate making security information as prominent and accessible as possible. > I don't think adding another for Security issues is a logical > division point with just two candidate chapters at this point. Perhaps poor communication on my part, as I wasn't proposing to create a new for only two chapters. Most of the sub-chapters within the existing Security chapter could easily be promoted to full chapters. For example, I have a patch for Kerberos5 being reviewed (hopefully ;-)) that will, as a by-product of covering more sub-topics, expand the sub-chapter by a noticable amount. My plan is to next write a second patch to cover the use of OpenSSH in a Kerberos environment. At that point it'll be almost unwieldy as a sub-chapter. I believe that it would be much better organized if it was a chapter rather than a subchapter -- it's now organized into broad section that would work well in that format, and when I see headings like "14.8.1.2.1" it's starting to resemble SNMP OIDs ;-) > Security topics are integral to both System Administration and Network > Services, and we shouldn't remove security information from those > parts to make a new one. Or, from a security guys point of view, security topics transcends both system administration and network services and we shouldn't be burying the security information ;-) > All of these proposals seem to have two things in common : > > 1. The security chapter is too big. > 2. The firewalls information should go into a separate chapter. I'd add: 3. Some of the security chapter sub-chapters are getting awfully large for the format 4. Making security information prominent and detailed is a worthwhile goal for the Handbook > Moving a chapter between parts is easy. So how about splitting out > the firewall content into a new 'firewalls/chapter.sgml' file, and > then temporarily adding this into the Network Services part. > > If it turns out that people do feel there is enough content for a > whole new dedicated to security, then it will just be a one > line diff to move the firewalls chapter from the network to a > new security . Sure, I have no problems with interim solutions. It's the same work either way, and "results trump theory" :-) - Tillman -- | <- You must be smarter than this stick to ride the Internet -- Mike Handler, paraphrased from Bev White