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

David Kreil kreil at ebi.ac.uk
Tue Jul 20 13:44:09 PDT 2004

Dear Allan,

Thank you very much for your many comments!

> > I still somewhat worry about the factor four in performance lost [...]
> One approach would be to gather statistics of peak performance
> requirements or do some stress-testing.  phk has added support for
> statistics collection in GEOM: see gstat(8).  You can simulate loads
> and benchmark with various tools found in ports.


> Outside of performance concerns: I wasn't suggesting you encrypt
> the device containing the root partition, as this is currently not
> supported since GBDE devices are mounted from userland gbde(8) during
> system startup from /etc/rc.d/gbde .  You can create a separate home
> partition and leave /usr unencrypted if usage cases won't dictate
> storage of site-specific data such as password files, etc.  You can
> setup /usr such that permissions are restrictive enough to ensure
> users can't write files to unprotected areas of the disk.
> What I meant to say was that if you can encrypt any sensitive areas and
> there is a workable trade-off between security and performance/usability,
> do so.  Even in the case that 98% of your information is mundane, it's
> the 2% such as private keys, proprietary communication/documents,
> etc. that ultimately matters.
> Finally, it's possible to use gbde in a loopback configuration w/
> md driver for finer granularity or for incremental addition of
> secure vnode-backed / temporary mounts.

I'm not sure I understand - are you suggesting to encrypt more selectively?
But which areas are senstive, and which are not?

I felt that as soon as I encrpyted /tmp and swap, I might performancewise just 
as well go for encrypting everything that contains dynamic information, for 
greatest simplicity. Then I don't have to think about whether there might be 
leakage, improving the security rating of one of the weakest links in the 
system - myself :o)

> > Thanks for pointing this out. The Handbook describes a basic gdbe
> > setup but mentions that getting other volumes (like /home) onto a
> > gdbe partition was trickier. Can you tell me which volumes you have
> > successfully put onto a gdbe partition and what was required to get
> > this working?
> I currently don't use the default script and have tested various
> configurations.  On all systems I've had /home partitioned separate
> to /usr which is a simple case of changing your /etc/fstab to the
> corresponding bde devices and setting the noauto flag, pass# to 0
> so as not to attempt filesystem check before attach:
> /dev/ar0g               /usr            ufs     rw              2       2
> /dev/ar0h.bde           /home           ufs     rw,noauto       2       0


> > I wonder, in particular, what issues I have to expect in wanting to keep
> > system relevant directories like /var on a gdbe partition.
> The gbde attach should occur early enough during multiuser startup to avoid
> such problems, I don't recall if the provided rc script would be sufficient,
> I'll test a configuration soon,

That would be great. I currently only have the system on and off, as we are 
still fiddling with the hardware (a disk went down again today).

> or let me know if you have any luck.

Yes, will report back if I do! :o)

> There are several approaches to securing /etc, but I can elaborate
> more after further testing.  The short term approach is not storing
> private keys, etc. on an unencrypted root.  Support for encrypted
> root is possible w/ some work, but there are a few issues to sort
> out first.

I think I don't need root to be encrypted per se, but /var, /etc, /usr/local, and /home would be good. As you say, the question is how to get these mounted early enough.

Success stories gratefully received!

With best regards,


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),'  ((!.-'

More information about the freebsd-fs mailing list