From owner-freebsd-fs@FreeBSD.ORG Fri Jul 16 04:51: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 986F416A4CE for ; Fri, 16 Jul 2004 04:51:42 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F54043D2D for ; Fri, 16 Jul 2004 04:51:42 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.10) with ESMTP id i6G4pZOF030001; Thu, 15 Jul 2004 21:51:35 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i6G4pZIo030000; Thu, 15 Jul 2004 21:51:35 -0700 Date: Thu, 15 Jul 2004 21:51:35 -0700 From: Brooks Davis To: David Kreil Message-ID: <20040716045134.GA28777@Odin.AC.HMC.Edu> References: <200407160422.i6G4Mrs04821@puffin.ebi.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <200407160422.i6G4Mrs04821@puffin.ebi.ac.uk> User-Agent: Mutt/1.5.4i cc: freebsd-fs@freebsd.org 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 04:51:42 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Please don't cross post so much.] On Fri, Jul 16, 2004 at 05:22:53AM +0100, David Kreil wrote: > to avoid leakage of sensitive information: any advice? > From: David Kreil >=20 > (1) I was wondering whether anyone knew of packages/tools to aid in=20 > "sanitizing" > a FreeBSD system, i.e., wiping > + the swap slice > + non-allocated space on volumes > + "file-tails" (the part of the last allocated block of files not used) > with random patterns to avoid leakage of sensitive information (plain tex= t=20 > keys or decrypted texts). >=20 > I am aware of the security limitations of any approach that does not invo= lve=20 > dissolving the entire disk in acid etc but would be grateful for a pointe= r to=20 > a tool that at least > + generates reasonably random data for its writes > + ideally does a reasonable effort of turning off caching whereever it c= ould > (ideally in the file system, the disk driver, and the disk itself) > or alternatively at least did the overwrites in such an order that the > effect of caching would be minimized. >=20 > If there are no "tools", would you know whether I can get FreeBSD on shut= down=20 > to stop using swap and access it as a raw disk device that I can write to= , and=20 > how to hook into the shutdown process? The only way to clean a file system I can think of is, to dump the fs, scrub the disk, restore the fs. That will keep only real data and remove all the junk. You should be able to scrub swap at shutdown if you use swapoff to disable it, but you've got to be sure it's all unused first. You can't trust this though because you don't know the system will shut down cleanly. 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=3D/dev/random of=3D/dev/ bs=3D dd if=3D/dev/zero of=3D/dev/ bs=3D This doesn't meet DoD requirements, but only for obsolete reasons. > (2) Related to this: >=20 > I'm also interested in people's personal experiences in using partition o= r=20 > file system encryption options. >=20 > For performance reasons I'd rather avoid having /tmp and swap and certain= work=20 > 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. -- Brooks --=20 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 --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA917WXY6L6fI4GtQRAkRFAJ9LHCkYPU3K6kpl332aJALe6rGmyACfe7CG u/Miuf5kB7TSTdGYBLu5mqU= =rIvU -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1--