From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 11:04:52 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 49D5E1065670 for ; Fri, 5 Feb 2010 11:04:52 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.srv.cat (smtp02.cdmon.com [212.36.74.57]) by mx1.freebsd.org (Postfix) with ESMTP id CB6358FC1C for ; Fri, 5 Feb 2010 11:04:50 +0000 (UTC) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) (Authenticated sender: jespasac@noverificar) by smtp02.srv.cat (Postfix) with ESMTP id 4C71F46E24 for ; Fri, 5 Feb 2010 12:04:48 +0100 (CET) Message-ID: <4B6BFB4F.5010505@minibofh.org> Date: Fri, 05 Feb 2010 12:04:47 +0100 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B696D0B.3070301@minibofh.org> <20100203134025.GA1787@icarus.home.lan> In-Reply-To: <20100203134025.GA1787@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 05 Feb 2010 11:04:52 -0000 > 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. Ok. It's exactly what I've supposed. > 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). Mmmmmm... I don't undestand this like secuiryt by obscurity; anyway you've the reason: kern.securelevel should be the correct path to follow. > 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. Thanks for comments. ;) -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear.