In our particular case, there won't be snapshots of destroyed filesystems (I 
create the snapshots, and destroy them with the filesystem).
I'm not too sure on the particulars of NFS/ZFS, but would it be possible to 
create a 1GB file without writing any data to it, and then use a hex editor to 
access the data stored on those blocks previously?  Any chance someone could 
make any kind of sense of the contents (allocated in the same order they were 
before, or what have you)?

ZFS crypto will be nice when we get either NFSv4 or NFSv3 w/krb5 for over the 
wire encryption.  Until then, not much point.

-
Cameron Hanover
chano...@umich.edu

"Our integrity sells for so little, but it is all we really have. It is the 
very last inch of us, but within that inch, we are free."
--Valerie (V for Vendetta)

On Feb 5, 2010, at 4:36 PM, Nicolas Williams wrote:

> On Fri, Feb 05, 2010 at 03:49:15PM -0500, c.hanover wrote:
>> Two things, mostly related, that I'm trying to find answers to for our
>> security team.
>> 
>> Does this scenario make sense:
>> * Create a filesystem at /users/nfsshare1, user uses it for a while,
>> asks for the filesystem to be deleted
>> * New user asks for a filesystem and is given /users/nfsshare2.  What
>> are the chances that they could use some tool or other to read
>> unallocated blocks to view the previous user's data?
> 
> If the tool isn't accessing the raw disks, then the answer is "no
> chance".  (There's no way to access the raw disks over NFS.)
> 
>> Related to that, when files are deleted on a ZFS volume over an NFS
>> share, how are they wiped out?  Are they zeroed or anything.  Same
>> question for destroying ZFS filesystems, does the data lay about in
>> any way?  (That's largely answered by the first scenario.)
> 
> Deleting a file does not guarantee that data blocks are released:
> snapshots might exist that retain references to the data blocks of a
> file that is being deleted.  Nor are blocks wiped when released.
> 
>> If the data is retrievable in any way, is there a way to a) securely
>> destroy a filesystem, or b) securely erase empty space on a
>> filesystem.
> 
> When ZFS crypto ships you'll be able to securely destroy encrypted
> datasets.  Until then the only form of secure erasure is to destroy the
> pool and then wipe the individual disks.
> 
> Nico
> -- 
> 
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to