From owner-freebsd-fs@FreeBSD.ORG Fri Jul 16 18:13:42 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B194416A4CE for ; Fri, 16 Jul 2004 18:13:42 +0000 (GMT) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 744BC43D39 for ; Fri, 16 Jul 2004 18:13:42 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id i6GIDem9020654; Fri, 16 Jul 2004 14:13:40 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id i6GIDdwu020653; Fri, 16 Jul 2004 14:13:39 -0400 (EDT) (envelope-from afields) Date: Fri, 16 Jul 2004 14:13:39 -0400 From: Allan Fields To: Brooks Davis Message-ID: <20040716181339.GA18056@afields.ca> References: <200407160422.i6G4Mrs04821@puffin.ebi.ac.uk> <20040716045134.GA28777@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040716045134.GA28777@Odin.AC.HMC.Edu> User-Agent: Mutt/1.4i cc: freebsd-fs@freebsd.org cc: David Kreil Subject: Re: "sanitizing" disks: wiping swap, non-allocated space, and file-tails X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2004 18:13:42 -0000 On Thu, Jul 15, 2004 at 09:51:35PM -0700, Brooks Davis wrote: > There is a currently null operation in the disk code that acts when > a block is no longer used. It should be possible to hook into that > code to implement some sort of scrubber. It wouldn't be reliable for > the same reason that a swap scrubber can't be, but it would be OK most > of the time. > > The easiest way to scrub a disk is: > > dd if=/dev/random of=/dev/ bs= > > dd if=/dev/zero of=/dev/ bs= > > This doesn't meet DoD requirements, but only for obsolete reasons. > > > (2) Related to this: > > > > I'm also interested in people's personal experiences in using partition or > > file system encryption options. > > > > For performance reasons I'd rather avoid having /tmp and swap and certain work > > space on an encrypted disk, hence the need for (1). > > If you swap, your performance will be suck enough that encrypting it > won't hurt much, especially with modern CPUs. I wouldn't worry at all > about that cost. /tmp is probably similar for most applications. Agreed, the simplest approach for base-level storage security is to encrypt it all. Hardware is cheap and fast enough. Trying to sweep-up afterward is more difficult, any way you look at it. Assessing leakage: it's quite possible users could inadvertently copy an important document to /tmp or a program could write to swap things that would be encrypted in on-disk counterparts. This is rightly identified as a weak-link here. Another thing to note is /var can contain sensitive data, the locate database and mail/print spools to name a few are potential areas of significance. Some also consider logs sensitive. > > -- Brooks > > -- > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 -- Allan Fields, AFRSL - http://afields.ca 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541