shred plugin

[Liviu Andronic]

Dear Tom,
Have you ever considered implementing a 'shred' plugin? Currently one
may delete files in emelFM2, but we all know that usually the file is
unlinked, while the underlying data stays on the harddisk. Shredding
tries to improve security by overwriting the underlying data with 0s
or some pseudo-random pattern.

It would be nice to have this in emelFM2. For example, such
functionality is present in Rodent ( http://xffm.foo-projects.org/ ).
Regards,
Liviu

[Geoff]

+1

On Mon, 19 Aug 2013 15:15:05 +0200

Post by Liviu Andronic
Dear Tom,
Have you ever considered implementing a 'shred' plugin?

[t***@onepost.net]

On Mon, 19 Aug 2013 17:18:43 +0100

+1

OK, I'll attend to it. However, we're on the verge of another release, and I doubt that a new plugin will make it in time.

Regards
Tom

[0.akowalski]

You also have my plus one ;-)

+1

Arkadiusz Kowalski

Post by t***@onepost.net
On Mon, 19 Aug 2013 17:18:43 +0100

+1

OK, I'll attend to it. However, we're on the verge of another release, and I
doubt that a new plugin will make it in time.
Regards
Tom
--
Users can unsubscribe from the list by sending email to
logging into the web interface.

[t***@onepost.net]

On Thu, 22 Aug 2013 12:45:59 +0200

Post by 0.akowalski
You also have my plus one ;-)

I hope we all realise that this will really be just a more-sophisticated approach to security-by-obscurity. AFAIK there's no bullet-proof and widely-available approach to forcing multiple, nearly-simultaneous overwrites, or dealing with OS page-files.

Regards
Tom

[Liviu Andronic]

Post by t***@onepost.net
On Thu, 22 Aug 2013 12:45:59 +0200

Post by 0.akowalski
You also have my plus one ;-)

I hope we all realise that this will really be just a more-sophisticated approach to security-by-obscurity. AFAIK there's no bullet-proof and widely-available approach to forcing multiple, nearly-simultaneous overwrites, or dealing with OS page-files.

I do remember reading that shredding on a journaling FS is not that
very efficient (I never understood why, though), but to my
understanding it should be pretty useful on a non-journaling FS (like
ext2 or fat32) that you would usually have on an external USB drive.

Regards,
Liviu

Post by t***@onepost.net
Regards
Tom
--

[Ralf ranfyy]

Post by t***@onepost.net

Post by t***@onepost.net
On Thu, 22 Aug 2013 12:45:59 +0200

Post by 0.akowalski
You also have my plus one ;-)

I hope we all realise that this will really be just a more-sophisticated

approach to security-by-obscurity. AFAIK there's no bullet-proof and
widely-available approach to forcing multiple, nearly-simultaneous
overwrites, or dealing with OS page-files.
I do remember reading that shredding on a journaling FS is not that
very efficient (I never understood why, though),

You can read up a bit on how revoering works on ext4 here:
http://openfacts2.berlios.de/wikien/index.php/BerliosProject:Ext4magic

[Liviu Andronic]

Post by Ralf ranfyy

Post by Liviu Andronic
I do remember reading that shredding on a journaling FS is not that
very efficient (I never understood why, though),

http://openfacts2.berlios.de/wikien/index.php/BerliosProject:Ext4magic

Thanks.

I also checked the man shred page, and it says:
"In the case of ext3 file systems, the above disclaimer applies (and
shred is thus of limited effectiveness) only in data=journal mode,
which journals file data in addition to just metadata. In both the
data=ordered (default) and data=writeback modes, shred works as usual."

So this would mean that shredding should work on ext3, too, under
certain configurations. I'm just wondering how to check whether my
ext3 partition is using defaults or some other 'data=' option? The
following is not very informative:

***@malou-laptop:~$ cat /etc/mtab | grep -i ext3
/dev/sda6 / ext3 rw,errors=remount-ro 0 0
/dev/sda8 /home ext3 rw,errors=remount-ro 0 0

Regards,
Liviu

[Liviu Andronic]

Dear Tom,

Post by t***@onepost.net
On Thu, 22 Aug 2013 12:45:59 +0200

Post by 0.akowalski
You also have my plus one ;-)

I hope we all realise that this will really be just a more-sophisticated approach to security-by-obscurity. AFAIK there's no bullet-proof and widely-available approach to forcing multiple, nearly-simultaneous overwrites, or dealing with OS page-files.

I've now played around with the new Shred plugin and applying it on a
file yielded the following:
Failed to remove
/tmp/1001-emelfm2-svn-unpack.tmp~1/bcrypt-master/Makefile - Success

Is this expected?

Furthermore, I peeked at the source code (I couldn't yet find docs for
the plugin) and it seems to me that this is a home-grown
implementation for a shredding algorithm. Is there a good reason to
not just re-use the thoroughly tested shred command that comes with
most Linux distros (and allow for some plug-in config options, like
nature of rewrite---zeros or pseudo-randoms---and nr of rewrites)?

Regards,
Liviu

[Liviu Andronic]

Post by Liviu Andronic
Dear Tom,

Post by t***@onepost.net
On Thu, 22 Aug 2013 12:45:59 +0200

Post by 0.akowalski
You also have my plus one ;-)

I hope we all realise that this will really be just a more-sophisticated approach to security-by-obscurity. AFAIK there's no bullet-proof and widely-available approach to forcing multiple, nearly-simultaneous overwrites, or dealing with OS page-files.

I've now played around with the new Shred plugin and applying it on a
Failed to remove
/tmp/1001-emelfm2-svn-unpack.tmp~1/bcrypt-master/Makefile - Success
Is this expected?
Furthermore, I peeked at the source code (I couldn't yet find docs for
the plugin) and it seems to me that this is a home-grown
implementation for a shredding algorithm. Is there a good reason to
not just re-use the thoroughly tested shred command that comes with
most Linux distros (and allow for some plug-in config options, like
nature of rewrite---zeros or pseudo-randoms---and nr of rewrites)?

One more thing: When launching Shred on a file, the dialogue asks
whether you want to _delete_ the file. I think both the message and
button should use _shred_.

Liviu

Post by Liviu Andronic
Regards,
Liviu

[t***@onepost.net]

On Tue, 27 Aug 2013 11:30:47 +0200

Post by Liviu Andronic

Post by Liviu Andronic
Dear Tom,

Post by t***@onepost.net
On Thu, 22 Aug 2013 12:45:59 +0200

Post by 0.akowalski
You also have my plus one ;-)

I hope we all realise that this will really be just a more-sophisticated approach to security-by-obscurity. AFAIK there's no bullet-proof and widely-available approach to forcing multiple, nearly-simultaneous overwrites, or dealing with OS page-files.

I've now played around with the new Shred plugin and applying it on a
Failed to remove
/tmp/1001-emelfm2-svn-unpack.tmp~1/bcrypt-master/Makefile - Success
Is this expected?
Furthermore, I peeked at the source code (I couldn't yet find docs for
the plugin) and it seems to me that this is a home-grown
implementation for a shredding algorithm. Is there a good reason to
not just re-use the thoroughly tested shred command that comes with
most Linux distros (and allow for some plug-in config options, like
nature of rewrite---zeros or pseudo-randoms---and nr of rewrites)?

One more thing: When launching Shred on a file, the dialogue asks
whether you want to _delete_ the file. I think both the message and
button should use _shred_.

Would need to re-factor the dialog code. Surely a user can remember what action was initiated a few seconds before ??

Regards
Tom

[t***@onepost.net]

On Tue, 27 Aug 2013 11:28:27 +0200

Post by Liviu Andronic

Post by t***@onepost.net
On Thu, 22 Aug 2013 12:45:59 +0200

Post by 0.akowalski
You also have my plus one ;-)

I hope we all realise that this will really be just a more-sophisticated approach to security-by-obscurity. AFAIK there's no bullet-proof and widely-available approach to forcing multiple, nearly-simultaneous overwrites, or dealing with OS page-files.

I've now played around with the new Shred plugin and applying it on a
Failed to remove
/tmp/1001-emelfm2-svn-unpack.tmp~1/bcrypt-master/Makefile - Success
Is this expected?

No, the appended "success" is a glitch.

Post by Liviu Andronic
Furthermore, I peeked at the source code (I couldn't yet find docs for
the plugin) and it seems to me that this is a home-grown
implementation for a shredding algorithm. Is there a good reason to
not just re-use the thoroughly tested shred command that comes with
most Linux distros (and allow for some plug-in config options, like
nature of rewrite---zeros or pseudo-randoms---and nr of rewrites)?

For the reasons described in recent posts on this list, among other places - multiple overwrites are more fantasy than reality in too many contexts.

The plugin does these:
* for a 'normal' file, change the file size randomly (bigger)
* fill the revised file with random content (or for links, a random target)
* for all types of item, change the name randomly
* put the item into /tmp or somewhere like that where lots of files would be
* change the mtime and atime randomly
* if possible, change some permissions
* finally - delete it

So, good luck with getting it back !

Regards
Tom

[t***@onepost.net]

On Mon, 19 Aug 2013 15:15:05 +0200

Post by Liviu Andronic
Have you ever considered implementing a 'shred' plugin? Currently one
may delete files in emelFM2, but we all know that usually the file is
unlinked, while the underlying data stays on the harddisk. Shredding
tries to improve security by overwriting the underlying data with 0s
or some pseudo-random pattern.
It would be nice to have this in emelFM2. For example, such
functionality is present in Rodent ( http://xffm.foo-projects.org/ ).

Considered, but not enough interest to construct one.

BTW, the encrypt plugin overwrites the original version of the file processed - not with E5 or 0 or whatever, but with random text from other files (supposedly to make it harder to automatically interrogate and discover any 'faint trace' of the original content).

Regards
Tom