Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Jul 2004 21:51:35 -0700
From:      Brooks Davis <brooks@one-eyed-alien.net>
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:  <20040716045134.GA28777@Odin.AC.HMC.Edu>
In-Reply-To: <200407160422.i6G4Mrs04821@puffin.ebi.ac.uk>
References:  <200407160422.i6G4Mrs04821@puffin.ebi.ac.uk>

next in thread | previous in thread | raw e-mail | index | archive | help

--n8g4imXOkfNTN/H1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[Please don't cross post so much.]

On Fri, Jul 16, 2004 at 05:22:53AM +0100, David Kreil wrote:
> to avoid leakage of sensitive information: any advice?
> From: David Kreil <kreil@puffin.ebi.ac.uk>
>=20
> (1) I was wondering whether anyone knew of packages/tools to aid in=20
> "sanitizing"
> a FreeBSD system, i.e., wiping
>   + the swap slice
>   + non-allocated space on volumes
>   + "file-tails" (the part of the last allocated block of files not used)
> with random patterns to avoid leakage of sensitive information (plain tex=
t=20
> keys or decrypted texts).
>=20
> I am aware of the security limitations of any approach that does not invo=
lve=20
> dissolving the entire disk in acid etc but would be grateful for a pointe=
r to=20
> a tool that at least
>  + generates reasonably random data for its writes
>  + ideally does a reasonable effort of turning off caching whereever it c=
ould
>    (ideally in the file system, the disk driver, and the disk itself)
>    or alternatively at least did the overwrites in such an order that the
>    effect of caching would be minimized.
>=20
> If there are no "tools", would you know whether I can get FreeBSD on shut=
down=20
> to stop using swap and access it as a raw disk device that I can write to=
, and=20
> how to hook into the shutdown process?

The only way to clean a file system I can think of is, to dump the fs,
scrub the disk, restore the fs.  That will keep only real data and
remove all the junk.  You should be able to scrub swap at shutdown if
you use swapoff to disable it, but you've got to be sure it's all unused
first.  You can't trust this though because you don't know the system
will shut down cleanly.

There is a currently null operation in the disk code that acts when
a block is no longer used.  It should be possible to hook into that
code to implement some sort of scrubber.  It wouldn't be reliable for
the same reason that a swap scrubber can't be, but it would be OK most
of the time.

The easiest way to scrub a disk is:

dd if=3D/dev/random of=3D/dev/<disk> bs=3D<something big>
<repeat a few times>
dd if=3D/dev/zero of=3D/dev/<disk> bs=3D<something big>

This doesn't meet DoD requirements, but only for obsolete reasons.

> (2) Related to this:
>=20
> I'm also interested in people's personal experiences in using partition o=
r=20
> file system encryption options.
>=20
> For performance reasons I'd rather avoid having /tmp and swap and certain=
 work=20
> space on an encrypted disk, hence the need for (1).

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.

-- Brooks

--=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

--n8g4imXOkfNTN/H1
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA917WXY6L6fI4GtQRAkRFAJ9LHCkYPU3K6kpl332aJALe6rGmyACfe7CG
u/Miuf5kB7TSTdGYBLu5mqU=
=rIvU
-----END PGP SIGNATURE-----

--n8g4imXOkfNTN/H1--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040716045134.GA28777>