Date: Tue, 20 Jul 2004 07:16:37 -0400 From: Allan Fields <bsd@afields.ca> 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: <20040720111637.GJ12833@afields.ca> In-Reply-To: <200407170204.i6H24eU16729@puffin.ebi.ac.uk> References: <20040716181339.GA18056@afields.ca> <200407170204.i6H24eU16729@puffin.ebi.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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=
=20
> mentioned in the gdbe paper. This is no problem for a set of sensitive pr=
ivate=20
> files but at the system level it does cause me worry. As you seem to be s=
o=20
> confident about this, however, (or have I misunderstood you?) I'll be hap=
py to=20
> 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 b=
ut=20
> mentions that getting other volumes (like /home) onto a gdbe partition wa=
s=20
> trickier. Can you tell me which volumes you have successfully put onto a =
gdbe=20
> 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:
=2E.
/dev/ar0g /usr ufs rw 2 2
/dev/ar0h.bde /home ufs rw,noauto 2 0
=2E.
> I wonder, in particular, what issues I have to expect in wanting to keep=
=20
> 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,
>=20
> David.
>=20
> ------------------------------------------------------------------------
> 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),' ((!.-'
--=20
Allan Fields, AFRSL - http://afields.ca
2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541
--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQFA/P8S90UNcjm0VUERAjMWAKCvT601qPxbW/uEvhDFbrJcCIHh2gCfSWBJ
P+gNc8w61zJmGmq5K12Kkgg=
=lCa0
-----END PGP SIGNATURE-----
--X1bOJ3K7DJ5YkBrT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040720111637.GJ12833>