Add shred example

[Erriez]

No description provided.

[lukefromdc]

This example words as expected when tested as mentioned in the docs (drop it into /usr/share/caja-python/extensions) does work, adding a "secure delete" context menu item that sucessfully invokes the "shred" command. While shred only works properly on spinning drives (on an SSD or flash drive the overwrites do NOT go over the original written blocks), that has nothing to do with whether this example works.

If we want to treat this as more than an example, we might want to document in some way that secure delete works only on spinning drives.

[cwendling]

FWIW, nautilus-wipe works with Caja as well. It's a tad under-loved, but that's what Tails currently has.
There's also scrub¹.

Anyway, as an example, why not, but as a real feature I think it's important to warn the users about potential problems, and possibly use a slightly better algorithm (or at least more transparent) than what shred does. shred is probably good enough for software attacks (although it lists is own limitations about actually overwriting stuff, which is more and more a problem with SSDs and such), but for hardware ones it might be trickier.

Footnotes

1. not sure what is the canonical homepage, but it seems to be at least a version of the right one. I know that Jim Galick is one of the authors anyway. ↩

[vkareh]

Added some comments and requested change.

[Erriez]

This example words as expected when tested as mentioned in the docs (drop it into /usr/share/caja-python/extensions) does work, adding a "secure delete" context menu item that sucessfully invokes the "shred" command. While shred only works properly on spinning drives (on an SSD or flash drive the overwrites do NOT go over the original written blocks), that has nothing to do with whether this example works.

If we want to treat this as more than an example, we might want to document in some way that secure delete works only on spinning drives.

First of all: Thanks for all your feedback. That's highly appreciated.

Correct: I started with an example as a secure erase feature which is not available in Caja. (Please correct me if I'm wrong)

The goal of this menu is to run a command which is able to:

• Erase the content of one or more files (fill with zero's or random values)
• Erase filename

You're right, overwriting files multiple times only makes sense for magnetic harddisks and not SSD's (which reduces lifetime).

For this example, I used the shred tool which available on any MATE system.

I'll consider and test a submenu, for example:

Feel free to share ideas for a better erase executable which is more secure.

Another point: It starts the shred process in the background and there is currently no progress bar or cancel button.

[Erriez]

FWIW, nautilus-wipe works with Caja as well. It's a tad under-loved, but that's what Tails currently has. There's also scrub1.

Anyway, as an example, why not, but as a real feature I think it's important to warn the users about potential problems, and possibly use a slightly better algorithm (or at least more transparent) than what shred does. shred is probably good enough for software attacks (although it lists is own limitations about actually overwriting stuff, which is more and more a problem with SSDs and such), but for hardware ones it might be trickier.

Footnotes

1. not sure what is the canonical homepage, but it seems to be at least a version of the right one. I know that Jim Galick is one of the authors anyway. [leftwards_arrow_with_hook](#user-content-fnref-1-bbfbeb93ae49ca384970093f58e3194f)

I considered nautilus-wipe which I used before on Ubuntu 22.04, but is not available on Ubuntu MATE 22.10:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.2 LTS
Release:	22.04
Codename:	jammy

$ apt list | grep nautilus-wipe

nautilus-wipe/jammy,now 0.3.1-2 amd64 [installed]

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.10
Release:	22.10
Codename:	kinetic

$ sudo apt install nautilus-wipe
E: Package 'nautilus-wipe' has no installation candidate

[cwendling]

I considered nautilus-wipe which I used before on Ubuntu 22.04, but is not available on Ubuntu MATE 22.10:

That's a bummer, because it should work (well, whether the Caja support is built in depends on the distro though). Admittedly there was not many changes upstream for a while, but mostly because it just worked. If anything is actually broken (in the dev version), report it :)

[Erriez]

If anything is actually broken (in the dev version), report it :)

Do you have a suggestion where I can report such issues? (I'm switching from Ubuntu to MATE because of many Wayland issues with Qt/PySide)

[cwendling]

If anything is actually broken (in the dev version), report it :)

Do you have a suggestion where I can report such issues?

https://wipetools.tuxfamily.org/nautilus-wipe.html#reporting-bugs 😉 Or just PM me, that will work as well (only risk is that if I haven't enough time I have a higher risk of forgetting a PM than a mail)

[Erriez]

If anything is actually broken (in the dev version), report it :)

Do you have a suggestion where I can report such issues?

https://wipetools.tuxfamily.org/nautilus-wipe.html#reporting-bugs wink Or just PM me, that will work as well (only risk is that if I haven't enough time I have a higher risk of forgetting a PM than a mail)

I'll send you an email. Thanks for your fast support!

[Erriez]

Changed to 4 submenu's and ready for review:

[lukefromdc]

This works, and the submenu works fine. Tested with an all zeros wipe, though this was on the desktop with on this machine is SSD so not an actual overwrite here.

Since this could fool new users (and be quite dangerous if it is police or intelligence agencies in a country like Iran recovering data), I would add to the submenu text indicating this works only on spinning drives and that on flash drives and SSD's the whole drive must be overwritten instead.

[Erriez]

@lukefromdc

• Added a disclaimer in the source about limited security as this is an example script.
• Renamed the first 2 menu's to Fill zero's and Fill random.
• The statusbar shows a not secure or HDD's only message.
• Menu Fill zero's: filenames + file data sectors filled with zero's.
• Menu Fill random: filenames + file data sectors filled with random data.
• Menu 3x overwrite, last zero\'s: filenames + file data sectors filled with zero's.
• Menu 3x overwrite (Default): filenames + file data sectors filled with random data.

The data and filenames on EXT4 filesystem with the shred menu's above are not easily recoverable with standard tools. I did not test other filesystems. However, the filesystem should be synced manually after shred as there may data left in cache.

Is this sufficient for you?

@cwendling See:

• Stackoverflow nautilus-wipe installation issue MATE 22.10.
• Stackoverflow no package libnautilus-extension configure/build issue on MATE 22.10.

[Erriez]

Wipe freespace menu's added:

Verified with wxHexEditor inspecting partition.

[lukefromdc]

This is about as good as we can get it. Note that each menu comes up when it makes sense: wipe freespace comes up when clicking on empty space in a directory, shred comes up when clicking on a file. Manual installation of the script necessary to install it, placing the comments documenting the limitations of shred in front of the user. Since we don't have tooltips on menu items, not a lot more we can do without making the menu very verbose.

Note that wiping empty space with random numbers after deleting a file IS a mostly secure (exception: part of a file on flash cells that fail to read-only after the file is written) way to clean camera cards etc. You can run this on a camera card, then check for remnants with photorec or foremost, destroy the card if anything potentially sensitve has gone read-only and survived and not before. I usually do this with dd if=/dev/random of= and check the whole device with photorec if the stuff being cleared is particularily sensitive.

A security minded distro (e.g. tails) could put this tool with in caja, and include the "how to" documentation with the distro's instructions

[Erriez]

@lukefromdc Thanks for your detailed description and testing. This triggered me to check directory write permission before starting the wipe or shred in commits 7809e45 and 016dadc.

[lukefromdc]

These are good checks to add. The shred utility itself does refuse to write to a file marked read-only for the
user in question(at least on my system...), but the "delete" and "move to trash" options do NOT. Apparently the delete command in caja is equivalent to rm -f <some file> . At least a deleted file can usually be recovered, but it cannot be if either it was shredded on an hdd or if it was deleted on a flash drive followed by overwriting all free space (or on an sdd if the OS has invoked trim for garbage collection). Thus we allow for the possibility of a future version of shred or a bug in shred allowing a write protected file to be shredded when it should not be

The dd command also fails (as it should) if the output is to a write protected directory. Again, it's good to take responsibility for this ourselves-and to show the user error dialogs showing what went wrong. The "error-directory is not writable" dialog is especially good for this, for a shredded file we get the generic "some files could not be shredded" dialog which is enough to warn users more needs to be done-or that they tried to kill a file they had marked read only for safekeeping.

Note that we are not greying out the menu items and making the command entirely nonresponsive, but since we don't do that on the remove and move to trash either this maintains a consistant UI. Not sure if this was originally an intentional decision by GNOME 2 Nautilus devs or not. If it was, it would be to avoid mystifying users about why these were greyed out if the users did not notice they didn't have write permission. GNOME 2 benefited from a $1M usability study by Sun Microsystems while it was under development.