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

Allan Fields bsd at afields.ca
Tue Jul 20 04:16:40 PDT 2004

On Sat, Jul 17, 2004 at 03:04:40AM +0100, David Kreil wrote:
> I still somewhat worry about the factor four in performance lost that is 
> mentioned in the gdbe paper. This is no problem for a set of sensitive private 
> files but at the system level it does cause me worry. As you seem to be so 
> confident about this, however, (or have I misunderstood you?) I'll be happy to 
> give it a go.

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.

> 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, or let me know if you have any luck.

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.

> With many thanks again for your help
> and best regards,
> 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),'  ((!.-'

 Allan Fields, AFRSL - http://afields.ca
 2D4F 6806 D307 0889 6125  C31D F745 0D72 39B4 5541
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20040720/2941d6ad/attachment.bin

More information about the freebsd-fs mailing list