From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 13:40:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75E9F106568B for ; Wed, 3 Feb 2010 13:40:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5CCD38FC0A for ; Wed, 3 Feb 2010 13:40:26 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta08.emeryville.ca.mail.comcast.net with comcast id dRcV1d0030vp7WLA8RgTcQ; Wed, 03 Feb 2010 13:40:27 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta05.emeryville.ca.mail.comcast.net with comcast id dRgS1d00D3S48mS8RRgSh9; Wed, 03 Feb 2010 13:40:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5D4021E3033; Wed, 3 Feb 2010 05:40:25 -0800 (PST) Date: Wed, 3 Feb 2010 05:40:25 -0800 From: Jeremy Chadwick To: Jordi Espasa Clofent Message-ID: <20100203134025.GA1787@icarus.home.lan> References: <4B696D0B.3070301@minibofh.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B696D0B.3070301@minibofh.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Inmutable bit in some binaries X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 13:40:27 -0000 On Wed, Feb 03, 2010 at 01:33:15PM +0100, Jordi Espasa Clofent wrote: > HI all, > > I'm hardening one test box and at present I'm planning to do: > > # chflags -R schg > > where will be some binaries that seems to be common targets > for rootkits and lammers: > > ls > du > ps > find > top > locate > strings > ifconfig > netstat login > > I wonder if changing these files permissions as I've shown above > will be cause some troubles in future upgrade (recompilation, the > classic way, not the binary upgrade one) process. żIt will? It's possible installworld will break (fail/exit) when trying to overwrite some of these binaries. However... install(1) supports the -f flags to specify what the destination file should have its file flags (chflags) set to, and from looking at the code (src/usr.bin/xinstall/xinstall.c), there are some places which indicate before copying/installing a file the software may attempt to unset file flags first. I'm not 100% familiar with this code, but it appears as if use of the -S flag to install(1) would cause it to behave like described. It should be easy enough for you to test. Otherwise, my recommendation is to build a test system / virtual box of some sort (VMware, etc.) and try it. See what happens. Opinion below: What you're attempting to solve, ultimately, is security through obscurity and gets you a very large headache. :-) Your schg idea would only work if you planned on using kern.securelevel=1 or higher. This sounds great in concept, but many a time on this list have people posted problems with system administrative tasks (re: upgrading) when this sysctl is set to non-default (-1). If you plan on using this, I would advocate *all* installation/work be done in single-user mode. I know quite a few people who completely ignore the "boot into single user" step of src/Makefile and instead do it in multi-user mode -- only to be found later screaming/crying when binaries don't work or behave oddly because, say, /libexec/ld-elf.so was supposed to be updated yet wasn't due to their choosing to not follow the proper procedure. If your system doesn't have an out-of-band method of getting to it (ex. serial console), then I wouldn't bother trying any of the above. Otherwise, I'm pretty sure others here have made use of read-only environments, such as read-only NFS root filesystems (sometimes accomplished via PXE) and/or /usr, or CD-based OS (good luck changing any files there). I can't help in that regard. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |