james hughes wrote:
This is intended as a defense in depth measure and also a sufficiently
good measure for the customers that don't need full compliance with
NIST like requirements that need degausing or physical destruction.
Govt, finance, healthcare all require the NIST overwrite...
james hughes wrote:
On Dec 20, 2006, at 1:37 PM, Bill Sommerfeld wrote:
On Wed, 2006-12-20 at 03:21 -0800, james hughes wrote:
This would be mostly a vanity erase not really a serious security
erase since it will not over write the remnants of remapped sectors.
Yup. As usual, your milage
Torrey McMahon wrote:
Darren Reed wrote:
Darren,
A point I don't yet believe that has been addressed in this
discussion is: what is the threat model?
Are we targetting NIST requirements for some customers
or just general use by everyday folks?
Even higher level: What problem are you/we
Darren Reed wrote:
Darren,
A point I don't yet believe that has been addressed in this
discussion is: what is the threat model?
There are several and this is about providing functionality so that
customers can choose what they want to use when it is appropriate.
Using format(1M) for whole
Bill Sommerfeld wrote:
There also may be a reason to do this when confidentiality isn't
required: as a sparse provisioning hack..
If you were to build a zfs pool out of compressed zvols backed by
another pool, then it would be very convenient if you could run in a
mode where freed blocks were
Matthew Ahrens wrote:
Darren J Moffat wrote:
I believe that ZFS should provide a method of bleaching a disk or part
of it that works without crypto having ever been involved.
I see two use cases here:
1. This filesystem contains sensitive information. When it is freed,
make sure it's
Not to add a cold blanket to this...
This would be mostly a vanity erase not really a serious security
erase since it will not over write the remnants of remapped sectors.
Serious security erase software will unmap sectors and erase both
locations using special microcode features. While
james hughes wrote:
Not to add a cold blanket to this...
This would be mostly a vanity erase not really a serious security
erase since it will not over write the remnants of remapped sectors.
Indeed and as you said there is other software to deal with this for
those types of customers that
On Dec 20, 2006, at 04:41, Darren J Moffat wrote:
Bill Sommerfeld wrote:
There also may be a reason to do this when confidentiality isn't
required: as a sparse provisioning hack..
If you were to build a zfs pool out of compressed zvols backed by
another pool, then it would be very convenient
Jonathan Edwards wrote:
On Dec 20, 2006, at 04:41, Darren J Moffat wrote:
Bill Sommerfeld wrote:
There also may be a reason to do this when confidentiality isn't
required: as a sparse provisioning hack..
If you were to build a zfs pool out of compressed zvols backed by
another pool, then it
On Wed, 2006-12-20 at 03:21 -0800, james hughes wrote:
This would be mostly a vanity erase not really a serious security
erase since it will not over write the remnants of remapped sectors.
Yup. As usual, your milage will vary depending on your threat model.
My gut feel is that there's
On Wed, 2006-12-20 at 03:21 -0800, james hughes wrote:
This would be mostly a vanity erase not really a serious security
erase since it will not over write the remnants of remapped sectors.
Yup. As usual, your milage will vary depending on your threat model.
My gut feel is that
, it is the drive manufacturers who are
in a position to address this.
Date: Wed, 20 Dec 2006 15:32:48 -0800 (PST)
From: Gary Winiger [EMAIL PROTECTED]
Subject: Re: [security-discuss] Re: [zfs-discuss] Thoughts on ZFS Secure
Delete - without using Crypto
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: zfs
On Dec 20, 2006, at 1:37 PM, Bill Sommerfeld wrote:
On Wed, 2006-12-20 at 03:21 -0800, james hughes wrote:
This would be mostly a vanity erase not really a serious security
erase since it will not over write the remnants of remapped sectors.
Yup. As usual, your milage will vary depending
On Dec 20, 2006, at 5:46 AM, Darren J Moffat wrote:
james hughes wrote:
Not to add a cold blanket to this...
This would be mostly a vanity erase not really a serious
security erase since it will not over write the remnants of
remapped sectors.
Indeed and as you said there is other
Darren,
A point I don't yet believe that has been addressed in this
discussion is: what is the threat model?
Are we targetting NIST requirements for some customers
or just general use by everyday folks?
Darrn
___
zfs-discuss mailing list
Darren Reed wrote:
Darren,
A point I don't yet believe that has been addressed in this
discussion is: what is the threat model?
Are we targetting NIST requirements for some customers
or just general use by everyday folks?
Even higher level: What problem are you/we trying to solve?
Darren Reed wrote:
If/when ZFS supports this then it would be nice to also be able
to have Solaris bleach swap on ZFS when it shuts down or reboots.
Although it may be that this option needs to be put into how we
manage swap space and not specifically zomething for ZFS.
Doing this to swap space
On Dec 19, 2006, at 08:59, Darren J Moffat wrote:
Darren Reed wrote:
If/when ZFS supports this then it would be nice to also be able
to have Solaris bleach swap on ZFS when it shuts down or reboots.
Although it may be that this option needs to be put into how we
manage swap space and not
On Dec 18, 2006, at 11:54, Darren J Moffat wrote:
[EMAIL PROTECTED] wrote:
Rather than bleaching which doesn't always remove all stains, why
can't
we use a word like erasing (which is hitherto unused for
filesystem use
in Solaris, AFAIK)
and this method doesn't remove all stains from
On Tue, 19 Dec 2006, Jonathan Edwards wrote:
On Dec 18, 2006, at 11:54, Darren J Moffat wrote:
[EMAIL PROTECTED] wrote:
Rather than bleaching which doesn't always remove all stains, why can't
we use a word like erasing (which is hitherto unused for filesystem use
in Solaris, AFAIK)
and
Frank Hofmann wrote:
On the technical side, I don't think a new VOP will be needed. This
could easily be done in VOP_SPACE together with a new per-fs property -
bleach new block when it's allocated (aka VOP_SPACE directly, or in a
backend also called e.g. on allocating writes / filling holes),
On Mon, 2006-12-18 at 16:05 +, Darren J Moffat wrote:
6) When modifying any file you want to bleach the old blocks in a way
very simlar to case 1 above.
I think this is the crux of the problem. If you fail to solve it, you
can't meaningfully say that all blocks which once contained parts
On Tue, 2006-12-19 at 16:19 -0800, Matthew Ahrens wrote:
Darren J Moffat wrote:
I believe that ZFS should provide a method of bleaching a disk or part
of it that works without crypto having ever been involved.
I see two use cases here:
I agree with your two, but I think I see a third use
Bill Sommerfeld wrote:
On Tue, 2006-12-19 at 16:19 -0800, Matthew Ahrens wrote:
Darren J Moffat wrote:
I believe that ZFS should provide a method of bleaching a disk or part
of it that works without crypto having ever been involved.
I see two use cases here:
I agree with your two, but I
[ This is for discussion, it doesn't mean I'm actively working on this
functionality at this time or that I might do so in the future. ]
When we get crypto support one way to do secure delete is to destroy
the key. This is usually a much simpler and faster task than erasing
and overwriting
Darren J Moffat wrote:
I think we need 5 distinct places to set the policy:
1) On file delete
This would be a per dataset policy.
The bleaching would happen in a new transaction group
created by the one that did the normal deletion, and would
run only if theoriginal
[EMAIL PROTECTED] wrote:
Rather than bleaching which doesn't always remove all stains, why can't
we use a word like erasing (which is hitherto unused for filesystem use
in Solaris, AFAIK)
and this method doesn't remove all stains from the disk anyway it just
reduces them so they can't be
28 matches
Mail list logo
