Date: Fri, 16 Jul 2004 14:13:39 -0400 From: Allan Fields <afields@afields.ca> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: David Kreil <kreil@ebi.ac.uk> Subject: Re: "sanitizing" disks: wiping swap, non-allocated space, and file-tails Message-ID: <20040716181339.GA18056@afields.ca> In-Reply-To: <20040716045134.GA28777@Odin.AC.HMC.Edu> References: <200407160422.i6G4Mrs04821@puffin.ebi.ac.uk> <20040716045134.GA28777@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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/<disk> bs=<something big> > <repeat a few times> > dd if=/dev/zero of=/dev/<disk> bs=<something big> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040716181339.GA18056>