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...
Jim,
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 "
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 tryin
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 mila
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,
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
zfs-discuss@
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 so
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 dependin
true, 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
> 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 fe
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 the
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 w
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 i
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 t
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
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 really
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 ov
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 thin
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 thi
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 really gone.
I believe that
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
Frank Hofmann wrote:
would not be a call to posix_fallocate() or ftruncate(), instead an
unlink(2) or a zfs destory or zpool destroy. Also on hotsparing in a
disk - if the old disk can still be written to in some way we should
do our best to bleach it.
Since VOP_*() requires a filesystem (wi
On Tue, 19 Dec 2006, Darren J Moffat wrote:
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
calle
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 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 t
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 t
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 speci
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
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 one c
[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 eas
>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 the
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 one compl
[ 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
33 matches
Mail list logo
