From owner-freebsd-chat Fri Feb 25 8:57: 3 2000 Delivered-To: freebsd-chat@freebsd.org Received: from ntstn.sasknow.com (h139-142-245-100.ss.fiberone.net [139.142.245.100]) by hub.freebsd.org (Postfix) with ESMTP id 5624F37C361 for ; Fri, 25 Feb 2000 08:56:59 -0800 (PST) (envelope-from ryan@sasknow.com) Received: from localhost (ryan@localhost) by ntstn.sasknow.com (8.9.3/8.9.3) with ESMTP id KAA99091; Fri, 25 Feb 2000 10:56:47 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Fri, 25 Feb 2000 10:56:47 -0600 (CST) From: Ryan Thompson Reply-To: Ryan Thompson To: Tim Brush Cc: freebsd-chat@FreeBSD.ORG Subject: Re: FreeBSD minimal install... In-Reply-To: <38B6850B.AAE49A00@avantgo.com> Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Cross-posted freebsd-questions removed from CC. Tim Brush wrote to freebsd-questions@FreeBSD.ORG and freebsd-chat@FreeBSD.ORG: > After performing a minimal installation I noticed a large number of > programs that are very useful for a generic installation but are not > necessarily useful for a specific server types (i.e. firewall, web > server, mail server, etc.). I've begun compiling a list of programs > that can (should?) be removed for specific servers (i.e. gcc, f77, uucp, > etc.). There is no purpose for these programs on a firewall. I > understand that removing these programs only add a tiny bit of security > but every little bit helps (you have much bigger problems if someone > gains unauthorized access to your systems). Hmm... I don't know if I would like to see that happen, for a couple of reasons: 1) As you have mentioned, it won't really make a system that much more secure. In fact, it would probably only accomplish a false sense of security. Many SysAdmins out there know the intricicies of system security, and would already be familiar with which programs they need to chmod 000 or delete outright. I certainly wouldn't trust a "template" to decide that for me on a critical production machine, and I'd probably spend just as much time verifying the setup as I would doing it from a normal install myself. As well, many SysAdmins do NOT know all that much about general system security, and would gladly select the peared down distribution, then go into panic mode when their system still gets cracked or DoS'ed, thinking they should have been protected. Imagine good old Charlie Root leaving a bunch of unencrypted, sensitive files on his machine because, hey, _my_ system is secure. Another scenario: If I built you a house without doors, would you leave $500 USD sitting in plain view through a window? 2) Disabling or not installing certain important parts of the base system, like (as you suggested) gcc, IMO, is NOT a good idea. If I go to fix or troubleshoot a broken FreeBSD system, I want to know what I'm working with. Imagine the flooding to freebsd-questions: "I took over a system from a friend, and I followed the advice in the faq about making the world... Why won't it work??" Or, "why can't I telnet into my machine"? Or "The system didn't come with ..., how do I get it back?" You see the idea. Perhaps if your idea was implemented with extensive documentation, on a command-by-command basis, with copious warning messages for each explaining WHAT the prospective SysAdmin is giving up, it might stave off some of the above problems. However, doing so would add a lot of text bloat to the already-stretched sysinstall. I really don't want to have to use THREE install floppies :-) Of course, it could be placed in an external text file, but that relies on the user actually reading it before installing. I don't want to suggest that people don't always read... But, well, people don't always read :-) - Ryan -- Ryan Thompson Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message