Behavior of tails with respect to shred, wipe, etc

Behavior of tails with respect to shred, wipe, etc

[Brett Russ]

Hi,

I have a few questions about the low level functionality of ReiserFS as it
pertains to overwriting a file in place from userland.  I am implementing
GNU shred on top of Reiser in metadata journaling only mode with tail
packing enabled.

To start off, I have several questions:

1) If I perform an exact file size shred (i.e. the file will not grow or
shrink as a result of the shred) of a file with a tail, can I be assured
that the write will occur over the existing data in all cases?
Specifically, will Reiser allocate a new block to store the overwritten
tail, thus abandoning the original data in the original block and defeating
the shred attempt?

2) If someone confirms that there is not a way to guarantee obliteration of
original data in all cases with tails, can I assume that disabling tails
will rectify the problem?

3) If I disable tail packing on mount (this is the only way, correct?) how
are previously tail packed blocks handled?  I can't imagine that ReiserFS
will go through all of them and unpack them--the performance hit of this
would be terrible no?  Does this only affect future writes?

4) What is the best way to determine and read the physical sectors that a
file is mapped to in order to verify obliteration?  I have used
debugreiserfs a bit (with the -d option) and get keys and locations of files
but the documentation is rather limited on what all of the output means and
how to use it.


Thanks for your help,
Brett

Re: Behavior of tails with respect to shred, wipe, etc

[Nikita Danilov]

Brett Russ writes:
 > Hi,
 > 
 > I have a few questions about the low level functionality of ReiserFS as it
 > pertains to overwriting a file in place from userland.  I am implementing
 > GNU shred on top of Reiser in metadata journaling only mode with tail
 > packing enabled.
 > 
 > To start off, I have several questions:
 > 
 > 1) If I perform an exact file size shred (i.e. the file will not grow or
 > shrink as a result of the shred) of a file with a tail, can I be assured
 > that the write will occur over the existing data in all cases?
 > Specifically, will Reiser allocate a new block to store the overwritten
 > tail, thus abandoning the original data in the original block and defeating
 > the shred attempt?

Tails are stored in leaf nodes of the balanced tree. During balancing
data are copied. When node becomes completely empty it is just dropped
on the floor and disk copy isn't updated. As a result, at any given
moment, some versions of file content can be scattered across different
disk blocks. Moreover, journal area also contains (multiple) copies of
data modified during recent transactions.

 > 
 > 2) If someone confirms that there is not a way to guarantee obliteration of
 > original data in all cases with tails, can I assume that disabling tails
 > will rectify the problem?

I think yes. Reiserfs neither relocates nor journals unformatted blocks
(until data-journalling patches are used).

 > 
 > 3) If I disable tail packing on mount (this is the only way, correct?) how
 > are previously tail packed blocks handled?  I can't imagine that ReiserFS
 > will go through all of them and unpack them--the performance hit of this
 > would be terrible no?  Does this only affect future writes?

Correct.

 > 
 > 4) What is the best way to determine and read the physical sectors that a
 > file is mapped to in order to verify obliteration?  I have used
 > debugreiserfs a bit (with the -d option) and get keys and locations of files
 > but the documentation is rather limited on what all of the output means and
 > how to use it.
 > 

Look for FIBMAP ioctl. It only works for unformatted blocks.

 > 
 > Thanks for your help,
 > Brett

I guess we should address this issue in reiser4. This is -security-
feature after all. Hans? It is not clear how to intehgrate this with
journalling though.

 > 

Nikita.

Re: Behavior of tails with respect to shred, wipe, etc

[Oleg Drokin]

Hello!

On Fri, Oct 25, 2002 at 07:55:30PM +0400, Nikita Danilov wrote:

>  > 2) If someone confirms that there is not a way to guarantee obliteration of
>  > original data in all cases with tails, can I assume that disabling tails
>  > will rectify the problem?
> I think yes. Reiserfs neither relocates nor journals unformatted blocks
> (until data-journalling patches are used).

Actually this is only true if file was not truncated prior to overwrite.

> I guess we should address this issue in reiser4. This is -security-
> feature after all. Hans? It is not clear how to intehgrate this with
> journalling though.

Zero out all freed blocks (mount option). This will kill write performance
though.

Bye,
    Oleg

Re: Behavior of tails with respect to shred, wipe, etc

[Nikita Danilov]

Oleg Drokin writes:
 > Hello!
 > 
 > On Fri, Oct 25, 2002 at 07:55:30PM +0400, Nikita Danilov wrote:
 > 
 > >  > 2) If someone confirms that there is not a way to guarantee obliteration of
 > >  > original data in all cases with tails, can I assume that disabling tails
 > >  > will rectify the problem?
 > > I think yes. Reiserfs neither relocates nor journals unformatted blocks
 > > (until data-journalling patches are used).
 > 
 > Actually this is only true if file was not truncated prior to overwrite.

Correct.

 > 
 > > I guess we should address this issue in reiser4. This is -security-
 > > feature after all. Hans? It is not clear how to intehgrate this with
 > > journalling though.
 > 
 > Zero out all freed blocks (mount option). This will kill write performance
 > though.

Journal would still retain copies.

 > 
 > Bye,
 >     Oleg

Nikita.

Re: Behavior of tails with respect to shred, wipe, etc

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]

On Fri, 25 Oct 2002 20:00:14 +0400, Oleg Drokin said:

> > I guess we should address this issue in reiser4. This is -security-
> > feature after all. Hans? It is not clear how to intehgrate this with
> > journalling though.
> 
> Zero out all freed blocks (mount option). This will kill write performance
> though.

This is the correct way to deal with "object reuse" in the Orange Book sense.

It's actually possible to (usually) do it without killing performance TOO
badly.  The way it's been implemented on other systems (for instance, the
"Clear Temp-Disk" support in IBM's VM operating system) has been along these
general lines:

1) When resource is freed, it does *NOT* go to the free list.  It is instead
put on a "to be cleaned" list.

2) A low-priority kernel thread then goes through and schedules a write of
a block of zeros, and as each write completes, *then* moves the page onto
the actual free list.  This can be optimized in a number of ways (for instance,
the obvious of only having 1 4K page and using it as the source for all the
writes - VM went one better and would launch one "CCW Chain" to clear
a cylinder at a time. If it knew there was a caching controller, it would
ensure the 4K page got into the cache, and then re-use it from there, resulting
in clearing a cylinder of 600K to 1.5M with only 6-8K of I/O bandwidth.  But
I don't think the average SCSI is that smart. ;)

This *is* subject to resource starvation if you have a lot of disk I/O *and*
a lot of file creation/deletion.  On the other hand, if it's something like
/tmp, it's probably time to use tmpfs so there's no need to worry about flushing
out the data.  Clever I/O scheduling will probably allow implementing
full data journalling *and* disk wiping with performance comparable to
journalling metadata only (think about it for a bit.. ;)
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Behavior of tails with respect to shred, wipe, etc

[Tom Vier]

On Fri, Oct 25, 2002 at 08:00:14PM +0400, Oleg Drokin wrote:
> > I guess we should address this issue in reiser4. This is -security-
> > feature after all. Hans? It is not clear how to intehgrate this with
> > journalling though.
> 
> Zero out all freed blocks (mount option). This will kill write performance
> though.

you could add support for the +s attr. zero-out current contents on delete.
it's sloppy, but like hans said, anyone serious about it should never let it
hit the disk unencrypted.

i'm the author of (one) wipe (aka ya-wipe, there's more than one "wipe") and
i made a point to be clear in the docs and on wipe.sf.net that encryption is
the only complete solution. my app is most useful for using on whole drives,
if you're going to sell it on ebay or something, and you want non-secret
personal stuff off (or at least invisible to almost all).

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0xE6CB97DA

Re: Behavior of tails with respect to shred, wipe, etc

[Oleg Drokin]

Hello!

On Tue, Oct 29, 2002 at 09:32:17PM -0500, Tom Vier wrote:
> > > I guess we should address this issue in reiser4. This is -security-
> > > feature after all. Hans? It is not clear how to intehgrate this with
> > > journalling though.
> > Zero out all freed blocks (mount option). This will kill write performance
> > though.
> you could add support for the +s attr. zero-out current contents on delete.

That won't work with editors that create temporary file, write new content into
it and then rename that temp file into new one.

> i'm the author of (one) wipe (aka ya-wipe, there's more than one "wipe") and
> i made a point to be clear in the docs and on wipe.sf.net that encryption is
> the only complete solution. my app is most useful for using on whole drives,

Another one (for deleted data to stay deleted) is to zero out all freed blocks
;)

> if you're going to sell it on ebay or something, and you want non-secret
> personal stuff off (or at least invisible to almost all).

Is that somehow better than badblocks -w /dev/hdX ? ;)

Bye,
    Oleg

Re: Behavior of tails with respect to shred, wipe, etc

[Tom Vier]

On Wed, Oct 30, 2002 at 09:36:28AM +0300, Oleg Drokin wrote:
> On Tue, Oct 29, 2002 at 09:32:17PM -0500, Tom Vier wrote:
> > > > I guess we should address this issue in reiser4. This is -security-
> > > > feature after all. Hans? It is not clear how to intehgrate this with
> > > > journalling though.
> > > Zero out all freed blocks (mount option). This will kill write performance
> > > though.
> > you could add support for the +s attr. zero-out current contents on delete.
> 
> That won't work with editors that create temporary file, write new content into
> it and then rename that temp file into new one.

true. it has several problems. i think ext2 still doesn't support it,
either.

> > i'm the author of (one) wipe (aka ya-wipe, there's more than one "wipe") and
> > i made a point to be clear in the docs and on wipe.sf.net that encryption is
> > the only complete solution. my app is most useful for using on whole drives,
> 
> Another one (for deleted data to stay deleted) is to zero out all freed blocks
> ;)

yes. you could make that a mount option, but i think it would be pointless.
if the data is that important, encrypt it. if it isn't, but it needs to be
wiped, wipe it when you get rid of the drive.

> > if you're going to sell it on ebay or something, and you want non-secret
> > personal stuff off (or at least invisible to almost all).
> 
> Is that somehow better than badblocks -w /dev/hdX ? ;)

yes, it's suppost to be. i personally wouldn't put my life on the line that
guttman's or anyone else's wipe patterns are any better than random data,
but some gov agency require drives be wiped using certain algorthyms (the
next version of my wipe is planned to include at least a few). the thing is,
even random data, overwritten 100 times, it's still theoretically possible
to retrieve the plaintext (random head offset, bad sector reallocation,
etc). i consider it just a matter of money. if someone wants to get data off
a drive, it's probably primarily a matter of time and money. the technology
to do atomic level imaging is there.

i highly recommend people read peter guttman's paper. i have a copy on my
site, his seems to have been moved:

http://wipe.sf.net/secure_del.html

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0xE6CB97DA

RE: Behavior of tails with respect to shred, wipe, etc

[Brett Russ]

> Tails are stored in leaf nodes of the balanced tree. During balancing
> data are copied. When node becomes completely empty it is just dropped
> on the floor and disk copy isn't updated. As a result, at any given
> moment, some versions of file content can be scattered across different
> disk blocks. Moreover, journal area also contains (multiple) copies of
> data modified during recent transactions.

It sounds like I cannot predict when balancing takes place, i.e. it doesn't
always occur as a result of writing the file I am concerned about
shredding--it might occur as a result of an unrelated operation.  So tails
can and will be scattered about and no longer attached to a shreddable
inode...hmm.

Your comment about the journal containing data--does that apply in my case
where I am only journaling metadata?

And if so, wouldn't a write/sync flush through the journal and clear that
out?

>  > 2) If someone confirms that there is not a way to guarantee
> obliteration of
>  > original data in all cases with tails, can I assume that
> disabling tails
>  > will rectify the problem?
>
> I think yes. Reiserfs neither relocates nor journals unformatted blocks
> (until data-journalling patches are used).

A full block or a partially full block with tail packing disabled is
considered an unformatted block?

>  > 4) What is the best way to determine and read the physical
> sectors that a
>  > file is mapped to in order to verify obliteration?  I have used
>  > debugreiserfs a bit (with the -d option) and get keys and
> locations of files
>  > but the documentation is rather limited on what all of the
> output means and
>  > how to use it.
>  >
>
> Look for FIBMAP ioctl. It only works for unformatted blocks.

Will check it out, thank you.

-Brett

Re: Behavior of tails with respect to shred, wipe, etc

[Nikita Danilov]

Brett Russ writes:
 > > Tails are stored in leaf nodes of the balanced tree. During balancing
 > > data are copied. When node becomes completely empty it is just dropped
 > > on the floor and disk copy isn't updated. As a result, at any given
 > > moment, some versions of file content can be scattered across different
 > > disk blocks. Moreover, journal area also contains (multiple) copies of
 > > data modified during recent transactions.
 > 
 > It sounds like I cannot predict when balancing takes place, i.e. it doesn't
 > always occur as a result of writing the file I am concerned about
 > shredding--it might occur as a result of an unrelated operation.  So tails

Right.

 > can and will be scattered about and no longer attached to a shreddable
 > inode...hmm.
 > 
 > Your comment about the journal containing data--does that apply in my case
 > where I am only journaling metadata?

Tails are meta-data: they are journalled.

 > 
 > And if so, wouldn't a write/sync flush through the journal and clear that
 > out?
 > 
 > >  > 2) If someone confirms that there is not a way to guarantee
 > > obliteration of
 > >  > original data in all cases with tails, can I assume that
 > > disabling tails
 > >  > will rectify the problem?
 > >
 > > I think yes. Reiserfs neither relocates nor journals unformatted blocks
 > > (until data-journalling patches are used).
 > 
 > A full block or a partially full block with tail packing disabled is
 > considered an unformatted block?

Not exactly. Distinction between formatted and unformatted is in their
relation to a balanced tree used by reiserfs. Formatted block is the
part of the tree. Formatted block consists of "items". Item has
"type". "Tail" is particular type of an item. Unformatted blocks don't
belong to the tree. Rather, tree contains "indirect items" that store
block number of the corresponding unformatted block. Content of the
tree, including tails and indirect items, is journalled. Parts of the
same file can be stored as tails (within tree) and unformatted blocks
(outside of the tree).

 > 
 > >  > 4) What is the best way to determine and read the physical
 > > sectors that a
 > >  > file is mapped to in order to verify obliteration?  I have used
 > >  > debugreiserfs a bit (with the -d option) and get keys and
 > > locations of files
 > >  > but the documentation is rather limited on what all of the
 > > output means and
 > >  > how to use it.
 > >  >
 > >
 > > Look for FIBMAP ioctl. It only works for unformatted blocks.
 > 
 > Will check it out, thank you.
 > 
 > -Brett
 > 

Nikita.

Re: Behavior of tails with respect to shred, wipe, etc

[Hans Reiser]

Nikita Danilov wrote:

>
>I guess we should address this issue in reiser4. This is -security-
>feature after all. Hans? It is not clear how to intehgrate this with
>journalling though.
>
> > 
>
>Nikita.
>
>
>  
>
Use encryption.  Encryption still leaves you vulnerable to those who can 
extract the key out of the owner though.

Hans

Re: Behavior of tails with respect to shred, wipe, etc

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

On Sat, 26 Oct 2002 05:41:10 +0400, Hans Reiser said:

> Use encryption.  Encryption still leaves you vulnerable to those who can 
> extract the key out of the owner though.

If you have multiple users on the same filesystem, key management becomes...
umm... "interesting".  Projects like loop-AES usually finesse it by only
having one key per filesystem.

It's 3AM, I'm going to avoid thinking about what's involved if *one* user on
a multi-user partition needs to change a compromised key.... ;)
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Behavior of tails with respect to shred, wipe, etc

[Hans Reiser]

Valdis.Kletnieks@vt.edu wrote:

>On Sat, 26 Oct 2002 05:41:10 +0400, Hans Reiser said:
>
>  
>
>>Use encryption.  Encryption still leaves you vulnerable to those who can 
>>extract the key out of the owner though.
>>    
>>
>
>If you have multiple users on the same filesystem, key management becomes...
>umm... "interesting".  Projects like loop-AES usually finesse it by only
>having one key per filesystem.
>
>It's 3AM, I'm going to avoid thinking about what's involved if *one* user on
>a multi-user partition needs to change a compromised key.... ;)
>  
>
Try thinking about what happens if you build a distributed filesystem 
with security based on keys, and you want to remove one user from access 
to a file.

;-)


This may be an inherent limitation on key based security.

We are going to allow users to supply whatever key they want to for 
encrypting a file in reiser4.1.  Unfortunately, due to  Halloween, it 
looks like reiser4.0 will have little in the way of new features, and 
all the new stuff will be delayed until 4.1, which will hopefully come 
out sometime around January.

Hans