From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 01:16:11 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 DA9E1106568B for ; Fri, 5 Feb 2010 01:16:11 +0000 (UTC) (envelope-from amesbury@umn.edu) Received: from mta-w3.tc.umn.edu (mta-w3.tc.umn.edu [134.84.119.32]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4E38FC13 for ; Fri, 5 Feb 2010 01:16:11 +0000 (UTC) Received: from optimator.oitsec.umn.edu (optimator.oitsec.umn.edu [160.94.247.212]) by mta-w3.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 4 Feb 2010 19:01:10 -0600 (CST) X-Umn-Remote-Mta: [N] optimator.oitsec.umn.edu [160.94.247.212] #+LO+TS+AU X-Umn-Classification: local Message-ID: <4B6B6DD5.10008@umn.edu> Date: Thu, 04 Feb 2010 19:01:09 -0600 From: Alan Amesbury User-Agent: Thunderbird 2.0.0.23 (X11/20100123) MIME-Version: 1.0 To: freebsd-stable@freebsd.org 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 01:16:12 -0000 Jeremy Chadwick said: > It's possible installworld will break (fail/exit) when trying to > overwrite some of these binaries. However... It will totally break installworld where installworld tries to replace the file. Been there, done that, and have the collector's edition soundtrack. [snip] > 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). I run at kern.securelevel=2 on most hosts at work and home. The only problems I've encountered are a) you can't do an installworld reliably (but see below!) b) buildworld sometimes fails c) X and other devices that use /dev/io break Workstation-class hosts don't use securelevel specifically because of "c". I don't need X on my servers so it doesn't get installed; no problems there. > 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 [snip] 100% agreement! I admit to occasionally taking shortcuts on this, but the majority of the time installworld and mergemaster are done in single-user. Every time I've had a problem with installworld while *not* doing this could be attributed to trying to do it in multi-user. The fact that buildworld will only *sometimes* fail in multi-user with kern.securelevel=2 is something that I consider to be a bug in the buildworld process, but not one serious enough that I've dug into it to find the root cause. The failure is almost always when attempting to touch the SSH binaries that show up under /usr/obj during the build; schg gets set on those at some point... but, again, I haven't bothered to figure out when or how. In those instances, I'm willing to reboot with securelevel disabled, do my work, then enable it again when I'm finished. This seems to work well. The only problems I see with applying schg and friends to other files is that it will complicate your upgrades. I suspect it's doable, though, provided you keep track of which files you're modifying. Then you can remove the flags prior to an upgrade, let buildworld/installworld do its thing, and reapply them when the work's complete. It's possible that mtree(8) might be very useful for documenting this sort of thing. > 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. Actually, sysutils/ezjail puts together a pretty nice framework that makes use of what's effectively a read-only OS with other things overlaid on top of it. That might work as an example, if one's needed. -- Alan Amesbury OIT Security and Assurance University of Minnesota