From owner-freebsd-advocacy@FreeBSD.ORG Tue Jan 13 14:10:29 2004 Return-Path: Delivered-To: freebsd-advocacy@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA9B816A4CE for ; Tue, 13 Jan 2004 14:10:29 -0800 (PST) Received: from fubar.adept.org (fubar.adept.org [63.147.172.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92D4943D5C for ; Tue, 13 Jan 2004 14:09:53 -0800 (PST) (envelope-from mike@adept.org) Received: from localhost (localhost [127.0.0.1]) by localhost.adept.org (Postfix) with ESMTP id 1A9DE15440 for ; Tue, 13 Jan 2004 14:09:53 -0800 (PST) Received: from fubar.adept.org ([127.0.0.1]) by localhost (fubar.adept.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 07772-08 for ; Tue, 13 Jan 2004 14:09:52 -0800 (PST) Received: from adept.org (mojo.televoke.net [63.237.196.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fubar.adept.org (Postfix) with ESMTP id 9AC0715239 for ; Tue, 13 Jan 2004 14:09:52 -0800 (PST) Message-ID: <40046CAF.7060709@adept.org> Date: Tue, 13 Jan 2004 14:09:51 -0800 From: Mike Hoskins User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031110 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-advocacy@freebsd.org References: <000b01c3d57f$a5c4d910$c701a8c0@diamond> <3FFCB0F2.6040206@adept.org> <200401111442.57782.dgw@liwest.at> In-Reply-To: <200401111442.57782.dgw@liwest.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD Today (modular devel tools? or what was it again?) X-BeenThere: freebsd-advocacy@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD Evangelism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2004 22:10:29 -0000 Daniela wrote: > What??? Remove the compiler for better security??? a lot of traditional security checklists have suggested "removing anything not absolutely necessary" when "hardening" machines. the idea is usually to make things as "hard as possible" for would-be attackers (as long as the changes are easy to manage, and removing/changing some subset of standard tools is certainly easy/scritable). many of the security measures put into place can often be worked around... it's by layering various approaches and making attacks hard for all but the (in)famous "determined attacker" that significant security is gained. in short, i don't currently do this on my boxes (although i have stripped a number of other "standard" binaries on firewall appliance machines before, using cfengine to regularly verify/enforce their removal... the same with removing SUID/SGID bits on utils i never use), but there is some arguable amount of "security relevance"... about the same as getting a car alarm... which any real thief can easily bypass. i also originally assumed anyone taking the time to write "compiler removal" into their security policies would have done enough auditing and analysis to understand what they were trying to gain (who does something like this ad-hoc? no one who plans to keep thier job.), and what other systemic tidbits may cause similar "problems". (having a hex editor lying around probably wouldn't be in line with that thought. ;)