"sanitizing" disks: wiping swap, non-allocated space, and file-tails

[David Kreil]

Dear Brooks,

Thank you very much again for your comments.

> > 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.

Ok, so if I do it after the processes' shutdown, any remaining stuff in 
virtual memory should easily fit into physical memory. swapoff would then move 
any swapped out pages back to physical memory before disconnecting swap and I 
can proceed.

Would you know how I could hook into the shutdown procedure *after* the 
processes have been terminated?

> > 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.

That sounds like coding it would require more disk interface knowledge than I 
have :-/

> > > The easiest way to scrub a disk is:
> > >
> > > dd if=/dev/random of=/dev/<disk> bs=<sthg big>
> > > <repeat a few times>

I noticed that it will refuse to let me do that on swap, even if it is off. Of 
course, I can edit the disklabel to read "unused", run dd, and restore the 
swap disklabel to "swap" but is there another way?

Also, I've just done some tests, and

  dd if=/dev/random of=/dev/<mydisk> bs=1048576

only writes at 6.5MB/s on my system (/dev/zero gives 7.9MB/s). Is that 
typical? My drives theoretically should do 30-40MB/s on read, and 20-30MB/s on 
write.

If these results are "normal", however, that means, for a 10GB swap file and, 
say 6 wipes, I'd be waiting 3h on shutdown, while a BND-safe thorough 20 wipes 
would take half a day. Not really practical :-/
So unless you tell me that I should be able to achieve much faster write 
speeds, I think I'll have to ditch the idea of regularly wiping swap (or 
anything else for that matter).


> > > This doesn't meet DoD requirements, but only for obsolete reasons.
> >
> > Interesting - can you say what type of reasons these are? :-)
> 
> The short form is that the DoD requirements require writing a pattern, a
> bit 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.

Ah, ok! Thanks for the pointers :)

> > > 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.
> >
> > 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).

That's impressive. Ok, I get the impression that in practice having everything that's not dedicated fast'n'dirty work-space gbde encrypted might after all be the best solution.

With many thanks again for your help,

David.


------------------------------------------------------------------------
Dr David Philip Kreil                 ("`-''-/").___..--''"`-._
Research Fellow                        `6_ 6  )   `-.  (     ).`-.__.`)
University of Cambridge                (_Y_.)'  ._   )  `._ `. ``-..-'
++44 1223 764107, fax 333992         _..`--'_..-_/  /--'_.' ,'
www.inference.phy.cam.ac.uk/dpk20   (il),-''  (li),'  ((!.-'