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
Marc-Christian Petersen <[email protected]> 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.
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)
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
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
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.
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
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.
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
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
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.
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: [email protected]
Any opinions expressed are solely my own.
"Albert D. Cahalan" <[email protected]> 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
Krzysztof Halasa writes:
> "Albert D. Cahalan" <[email protected]> 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.