Date: Mon, 19 Jul 2004 09:43:34 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: David Kreil <kreil@ebi.ac.uk> Cc: freebsd-fs@freebsd.org Subject: Re: "sanitizing" disks: wiping swap, non-allocated space, and file-tails Message-ID: <20040719164334.GA14144@Odin.AC.HMC.Edu> In-Reply-To: <200407170154.i6H1sTm14158@puffin.ebi.ac.uk> References: <20040716045134.GA28777@Odin.AC.HMC.Edu> <200407170154.i6H1sTm14158@puffin.ebi.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
--YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 17, 2004 at 02:54:29AM +0100, David Kreil wrote: >=20 > Dear Brooks, >=20 > Many thanks for your fast and helpful reply! >=20 > > [Please don't cross post so much.] >=20 > I'm sorry. I had sent it to "ports" two weeks ago, assuming that external= =20 > programs might be required and then didn't quite know where to turn next.= I=20 > guess I should have tried individual groups at a time. In general, just 1-2 lists is best. Idealy, you can send to a list a wait a few days before trying somewhere else. > > 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. >=20 > Ok, I can do that once to start from a clean slate but it would not be=20 > practical to do this regularly. Other then encrypting the disk, there isn't much else you can do at this point without kernel modification. > > 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. > >=20 > > 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. >=20 > Yes, both approaches would already improve my situation considerably. >=20 > The handbook says that a shutdown "will attempt to run the script > /etc/rc.shutdown, and then proceed to send all processes the TERM > signal, and subsequently the KILL signal to any that do not terminate > timely". Would turning off swap and scrubbing in rc.shutdown be > sufficient, or do I need a way of doing this *after* all other > processes have been terminated (and if so, what would be a good > approach)? I believe you would need to hook after process shutdown unless you're 100% sure you won't be using swap since you can't disable swap if it's in use. > You mentioned the possibility of hooking a scrub routine into the fs > code that releases a block. My main worry with such an approach would > be that repeated random writes of an individual block would probably > never really be written to disk due to drive caching etc. Is there a > way around this problem? With ATA disks, you can disable write caching which should work. With SCSI disks, you could force each block to disk individualy, in the correct order. > > The easiest way to scrub a disk is: > >=20 > > dd if=3D3D/dev/random of=3D3D/dev/<disk> bs=3D3D<something big> > > <repeat a few times> > > dd if=3D3D/dev/zero of=3D3D/dev/<disk> bs=3D3D<something big> > >=20 > > This doesn't meet DoD requirements, but only for obsolete reasons. >=20 > Interesting - can you say what type of reasons these are? :-) The short form is that the DoD requirements require writing a pattern, a fit flipped version of the pattern, and the pattern again followed by some set of characters, usually zeros. Unfortunaly, this method was designed for an encoding technique that has not been used in >20 years so it doens't work. For the long form, read the standard: http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-025.2.html and a nice modern analysis: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > > > (2) Related to this: > > > I'm also interested in people's personal experiences in using partiti= on > > > or file system encryption options. > > > For performance reasons I'd rather avoid having /tmp and swap and cer= tain=3D > > > work space on an encrypted disk, hence the need for (1). > >=20 > > 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. >=20 > Really? A loss in disk performance of factor of four should be > noticable I had thought. For swap, I don't think a factor of four will be noticable since that just makes accessing swap 4000 times slower then accessing RAM instead of 1000 times slower (example numbers of course). For file systems, it's going to depend heavily on your application. Many of them just don't use that much disk. I believe phk said buildworld wasn't all that much worse then before (I don't recall an actual number). -- 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 --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA+/ozXY6L6fI4GtQRAqZzAJ467oPJFXvbr55NDM17AuzOF+928QCgsaOl k1IPK1DffMCkYAwxTv8XVUw= =sGx7 -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040719164334.GA14144>