Where is ext2/3 secure delete ("s") attribute?

Where is ext2/3 secure delete ("s") attribute?

[Kent Borg]

I happened upon the chattr command and was pleased to see that "s"
means to write zeros (or is it random data?) to the blocks of deleted
files.  Cool, except I can't see that it works.

First, deleting a large file with the "s" attribute happens far too
quickly.

Second, I can't see where any of this is implemented in the source
code (as of Red Hat's 2.4.18-17.7.x and straight 2.4.19).  The file
fs/ext2/CHANGES talks about how the zero writing was changed to
writing random data--but nothing seems to implement this.

What happened to this feature?  Was it too slow or buggy?  Did the
Federales force its removal?

(Would this be best implemented as a background scrub and I am missing
a daemon?)


Thanks,

-kb, the Kent who would like to have his notebook not be full of
easily undeletable files.

Re: Where is ext2/3 secure delete ("s") attribute?

[Jeff Garzik]

Kent Borg wrote:

> What happened to this feature?  Was it too slow or buggy?  Did the
> Federales force its removal?
>
> (Would this be best implemented as a background scrub and I am missing
> a daemon?)


man shred(1)

Much better than anything implemented in-kernel

	Jeff

Re: Where is ext2/3 secure delete ("s") attribute?

[Kent Borg]

On Thu, Nov 21, 2002 at 01:24:39PM -0500, Jeff Garzik wrote:
> man shred(1)
> 
> Much better than anything implemented in-kernel

Yes, but that will only apply to files that I specifically shred.  I
hazard that a lot more files than the ones I explicitly "rm" in a day
get deleted by other means.  Also, the shred man page even says that
it doesn't know if its "shredding" even happens in the same spot on
disk as the original data resided.  It seems this has to happen down
in the file system if there is any hope of it working.  And even there
it could use come help from the disk drive to make sure things can be
made to happen where they appear to happen.


-kb

Re: Where is ext2/3 secure delete ("s") attribute?

[Alan Cox]

On Thu, 2002-11-21 at 18:39, Kent Borg wrote:
> disk as the original data resided.  It seems this has to happen down
> in the file system if there is any hope of it working.  And even there
> it could use come help from the disk drive to make sure things can be
> made to happen where they appear to happen.

Very real issue. Your IDE and SCSI disks may randomly leave recoverable
data around if they hit a block that is iffy and mark it bad before it
fails. Flash file systems are very very likely to leave old data around
but fortunately are much smaller and therefore easy to encrypt or blank
wholesale (or indeed blowtorch erase 8))

Re: Where is ext2/3 secure delete ("s") attribute?

[Kent Borg]

On Thu, Nov 21, 2002 at 07:20:58PM +0000, Alan Cox wrote:
> Flash file systems are very very likely to leave old data around

Another example of why this needs to be done in the file system.  (And
that help is sometimes needed from the "disk" particularly in cases
like flash IDE rives.)

And even if done well in ext2/3 it would not likely be flawless.
Still, it seems one of those cases where perfect can be the enemy of
good.

Something tells me that when the s-attribute was abandoned there were
not many Linux notebooks being carried around.  What with RAM having
been limited a swap hard on NiCd batteries.

Also, encryption keys can be coerced in many cases where on-going
secure deletion would remain secure.  Linux is picking up other
security features, it might be time to revisit this.


-kb, the Kent who is still curious about the history of the
s-attribute even as the thread threatens to drift off.

Re: Where is ext2/3 secure delete ("s") attribute?

[Alan Cox]

On Thu, 2002-11-21 at 19:05, Kent Borg wrote:
> Another example of why this needs to be done in the file system.  (And
> that help is sometimes needed from the "disk" particularly in cases
> like flash IDE rives.)

The file system can't do it
The flash device won't give you the info to do it
The ide disk wont give you the info to do it

Its possibly a polite hint from the universe to use encryption 8)

Re: Where is ext2/3 secure delete ("s") attribute?

[Jeff Garzik]

If you _really_ care about this, don't use a system that stores your 
bytes unencrypted on the platter.  Use a crypto loopback filesystem or 
somesuch.  Otherwise there will always be info leaks.

Where is ext2/3 secure delete ("s") attribute?

[Marc-Christian Petersen]

Hi Kent,

> What happened to this feature?  Was it too slow or buggy?  Did the
> Federales force its removal?
dunno, but:

man 1 chattr:

BUGS AND LIMITATIONS
       As  of  Linux  2.2,  the  `c',  's',  and `u' attribute are not honored
       by the kernel filesystem code. These attributes will be implemented in
       a future ext2 fs version.

Curious to see when the future is ;)

ciao, Marc

Re: Where is ext2/3 secure delete ("s") attribute?

[Harald Arnesen]

Marc-Christian Petersen <m.c.p@wolk-project.de> writes:

> BUGS AND LIMITATIONS
>        As  of  Linux  2.2,  the  `c',  's',  and `u' attribute are not honored
>        by the kernel filesystem code. These attributes will be implemented in
>        a future ext2 fs version.
>
> Curious to see when the future is ;)

Anyway, it would be false security. Any government agency (or IBAS in
Norway) may be able to reconstruct any data on your hd, or they may not.
But you can't know it. So if you _really_ want to have private data on
you computer, strong encryption is the only solution. And be sure that
every temporary file is encrypted!
-- 
Hilsen Harald.

Re: Where is ext2/3 secure delete ("s") attribute?

[Albert D. Cahalan]

Alan Cox writes:
> On Thu, 2002-11-21 at 19:05, Kent Borg wrote:

>> Another example of why this needs to be done in the file system.  (And
>> that help is sometimes needed from the "disk" particularly in cases
>> like flash IDE rives.)
>
> The file system can't do it
> The flash device won't give you the info to do it
> The ide disk wont give you the info to do it

That's being an idealist. You can protect against everybody
except the NSA and the disk manufacturer. Most likely they'd
need to spend lots of money in a clean room to get your data.

Forget the shred program. It's less useful than having the
filesystem simply zero the blocks, because it's slow and you
can't be sure to hit the OS-visible blocks. Aside from encryption,
the useful options are:

1. plain old rm  (protect from users)
2. filesystem clears the blocks  (protect from root/kernel)
3. physically destroy the disk  (protect from NSA & manufacturer)

Re: Where is ext2/3 secure delete ("s") attribute?

[Jeff Garzik]

Albert D. Cahalan wrote:

> Forget the shred program. It's less useful than having the
> filesystem simply zero the blocks, because it's slow and you
> can't be sure to hit the OS-visible blocks.


Why not?

Please name a filesystem that moves allocated blocks around on you.  And 
point to code, too.

	Jeff

Re: Where is ext2/3 secure delete ("s") attribute?

[Albert D. Cahalan]

Jeff Garzik writes:
> Albert D. Cahalan wrote:

>> Forget the shred program. It's less useful than having the
>> filesystem simply zero the blocks, because it's slow and you
>> can't be sure to hit the OS-visible blocks.
>
> Why not?
>
> Please name a filesystem that moves allocated blocks around on you.  And 
> point to code, too.

Reiserfs tails
  fs/reiserfs

ext3 with data journalling
  fs/ext3

the journalling flash filesystems
  fs/jffs
  fs/jffs2

NTFS with compression
  fs/ntfs


Some of these are listed in the shred man page.

Multiple overwrites won't protect you from the disk manufacturer
or the NSA. Only one is needed to protect against root & kernel.
So it makes sense to have the filesystem zero the blocks when
they are freed from a file.

Re: Where is ext2/3 secure delete ("s") attribute?

[Jeff Garzik]

Albert D. Cahalan wrote:

> Jeff Garzik writes:
>
> >Albert D. Cahalan wrote:
>
>
> >>Forget the shred program. It's less useful than having the
> >>filesystem simply zero the blocks, because it's slow and you
> >>can't be sure to hit the OS-visible blocks.
> >
> >Why not?
> >
> >Please name a filesystem that moves allocated blocks around on you.  And
> >point to code, too.
>
>
> Reiserfs tails
>   fs/reiserfs


inodes don't move

> ext3 with data journalling
>   fs/ext3


the allocated blocks don't change


> the journalling flash filesystems
>   fs/jffs
>   fs/jffs2


yep

> NTFS with compression
>   fs/ntfs


the allocated blocks don't change


> Multiple overwrites won't protect you from the disk manufacturer
> or the NSA. Only one is needed to protect against root & kernel.
> So it makes sense to have the filesystem zero the blocks when
> they are freed from a file.


if you need to protect against root, then zeroing the blocks isn't going 
to help for LVM or jffs or other journalling.

	Jeff

Re: Where is ext2/3 secure delete ("s") attribute?

[Albert D. Cahalan]

Jeff Garzik writes:
> Albert D. Cahalan wrote:
>> Jeff Garzik writes:

>>> Please name a filesystem that moves allocated blocks around
>>> on you.  And point to code, too.
>>
>> Reiserfs tails
>>   fs/reiserfs
>
> inodes don't move

In that case I suppose you could iterate through all possible
tail sizes. In any case, Reiserfs 4 is coming. Reiserfs 4 shifts
the tree all over.

>> ext3 with data journalling
>>   fs/ext3
>
> the allocated blocks don't change

Same effect though: only the filesystem driver can know how
to overwrite a file.

>> the journalling flash filesystems
>>   fs/jffs
>>   fs/jffs2
>
> yep
>
>> NTFS with compression
>>   fs/ntfs
>
> the allocated blocks don't change

They must. I suppose that might not be implemented yet.

>> Multiple overwrites won't protect you from the disk manufacturer
>> or the NSA. Only one is needed to protect against root & kernel.
>> So it makes sense to have the filesystem zero the blocks when
>> they are freed from a file.
>
> if you need to protect against root, then zeroing the blocks isn't
> going to help for LVM or jffs or other journalling.

By "protect against root" of course I mean a future cracked box
or the drive put into another machine.

LVM has to cooperate. If it can't, then that's a bug. Snapshots
count the same as keeping backups on separate media. Likewise,
fsck and defraggers need to cooperate.

Re: Where is ext2/3 secure delete ("s") attribute?

[Ingo Oeser]

On Thu, Nov 21, 2002 at 08:30:35PM -0500, Jeff Garzik wrote:
> Please name a filesystem that moves allocated blocks around on you.  And 
> point to code, too.

TUX2 from Daniel Phillips. No in kernel and might not ever be,
buts a good argument, because there it is by design ;-)

Regards

Ingo Oeser
-- 
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth

Re: Where is ext2/3 secure delete ("s") attribute?

[Alan Cox]

On Fri, 2002-11-22 at 01:30, Jeff Garzik wrote:
> Albert D. Cahalan wrote:
> 
> > Forget the shred program. It's less useful than having the
> > filesystem simply zero the blocks, because it's slow and you
> > can't be sure to hit the OS-visible blocks.
> 
> 
> Why not?
> 
> Please name a filesystem that moves allocated blocks around on you.  And 
> point to code, too.

Anything on IDE or SCSI or Flash. Just its done below you

Re: Where is ext2/3 secure delete ("s") attribute?

[Nikita Danilov]

Alan Cox writes:
 > On Fri, 2002-11-22 at 01:30, Jeff Garzik wrote:
 > > Albert D. Cahalan wrote:
 > > 
 > > > Forget the shred program. It's less useful than having the
 > > > filesystem simply zero the blocks, because it's slow and you
 > > > can't be sure to hit the OS-visible blocks.
 > > 
 > > 
 > > Why not?
 > > 
 > > Please name a filesystem that moves allocated blocks around on you.  And 
 > > point to code, too.
 > 
 > Anything on IDE or SCSI or Flash. Just its done below you

Journalling file systems also may leave copies of data in the journal area(s).

 > 

Nikita.

Re: Where is ext2/3 secure delete ("s") attribute?

[Mike Dresser]

On Thu, 21 Nov 2002, Albert D. Cahalan wrote:

> 3. physically destroy the disk  (protect from NSA & manufacturer)

And besides, where else can you have the fun of drilling out that stubborn
cover screw, and the fun of bashing up a set of platters with a hammer?
It's almost too bad we don't have any of those glass plattered IBM's, I'd
like ot see how they take a hammer.  Maxtor 13.6 gig drives just get
banged up a lot, nothing special like shattering or anything.

I should run a drive over to one of our 400 ton TOS presses, and see if
"pancake thin" is possible.

Mike

Re: Where is ext2/3 secure delete ("s") attribute?

[Jesse Pollard]

On Thursday 21 November 2002 07:22 pm, Albert D. Cahalan wrote:
> Alan Cox writes:
> > On Thu, 2002-11-21 at 19:05, Kent Borg wrote:
> >> Another example of why this needs to be done in the file system.  (And
> >> that help is sometimes needed from the "disk" particularly in cases
> >> like flash IDE rives.)
> >
> > The file system can't do it
> > The flash device won't give you the info to do it
> > The ide disk wont give you the info to do it
>
> That's being an idealist. You can protect against everybody
> except the NSA and the disk manufacturer. Most likely they'd
> need to spend lots of money in a clean room to get your data.

incomplete list....
	NSA
	DoD
	Homeland Defense gestapo
	disk manufacturer
	anybody willing to spend about $1000-$5000.

And I'm not sure it is impossible to just reset the bad block list either.
I've been able to do that to SCSI drives in the past, so I think it is
still possible to do.
	
> Forget the shred program. It's less useful than having the
> filesystem simply zero the blocks, because it's slow and you
> can't be sure to hit the OS-visible blocks. Aside from encryption,
> the useful options are:
>
> 1. plain old rm  (protect from users)
> 2. filesystem clears the blocks  (protect from root/kernel)
> 3. physically destroy the disk  (protect from NSA & manufacturer)

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Where is ext2/3 secure delete ("s") attribute?

[Krzysztof Halasa]

"Albert D. Cahalan" <acahalan@cs.uml.edu> writes:

> Forget the shred program. It's less useful than having the
> filesystem simply zero the blocks, because it's slow and you
> can't be sure to hit the OS-visible blocks. Aside from encryption,
> the useful options are:
> 
> 1. plain old rm  (protect from users)
> 2. filesystem clears the blocks  (protect from root/kernel)

It won't protect you from the root. If you need protection from root,
be a root on your own machine. And be sure your unencrypted data, keys
etc. never make it to/through any hostile system.
-- 
Krzysztof Halasa
Network Administrator

Re: Where is ext2/3 secure delete ("s") attribute?

[Albert D. Cahalan]

Krzysztof Halasa writes:
> "Albert D. Cahalan" <acahalan@cs.uml.edu> writes:

>> Forget the shred program. It's less useful than having the
>> filesystem simply zero the blocks, because it's slow and you
>> can't be sure to hit the OS-visible blocks. Aside from encryption,
>> the useful options are:
>>
>> 1. plain old rm  (protect from users)
>> 2. filesystem clears the blocks  (protect from root/kernel)
>
> It won't protect you from the root.

Sure it will. Like this:

1. you're a user, possibly root, on your own machine
2. you zero the disk blocks of a file
3. somebody cracks root
4. they look for the file -- not there
5. they read /dev/hda to find the data -- not there
6. they modify the kernel -- nope, data still not there

As long as nobody physically opens the drive, it would take some
seriously bad luck involving bad sectors to make your data at all
vulnerable... to somebody with drive manufacturer trade secrets.
If this worries you, destroy the drive and/or make an appointment
with your mental health professional.

Nothing counts if root is already malicious, so that issue
wasn't being addressed. You'd have keyboard snooping,
encryption tools that save a copy, man-in-the middle attacks
on everything... forget it. It's not worth discussing.