"sanitizing" disks: wiping swap, non-allocated space, and
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
> With many thanks again for your help
> and 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),' ((!.-'
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
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