LWN: Comments on "Secure deletion and trash bin support"

Secure deletion and trash bin support

renox — Thu, 14 Dec 2006 10:05:29 +0000

>>The nicest file manager available will not be able do do anything about an "rm" command typed into a shell,[...]
>Ummm, that's a feature, not a bug.

Depends, some of us believe that command-line interface and GUIs should behave *consistently*, as much as possible.

Secure deletion and trash bin support

martin@zeroscale.com — Sat, 09 Dec 2006 07:59:17 +0000

In my opinion there is no need for a Trash system within the kernel. Look at Mac OS X, their Finder
application handles the Trash, not the kernel. If you do "rm", your file is deleted. People who work
on that level don't want a Trash.

The idea of secure deletion feature I like. But this should be handled by the filesystems or the VFS,
not send back to userspace by putting it in the trash. If userspace has to handle it anyway, it does
not need the trash to blank a file before deletion.

But it is again Mac OS X which can teach us a lesson: Look at their idea of "Timemaschine".
Something like this is way more useful than a dot-root-trash sitting somewhere.

trash bin

giraffedata — Fri, 08 Dec 2006 19:23:54 +0000

Presence of a .trash directory (a filesystem option) and a mount option are two different things, both valuable. In reality, I think users wouldn't be satisfied with undeletion without an entire storage management policy capability. The decision whether to delete a file as soon as the last normal reference disappears or keep it around in the trash needs to be based on what directory, filesystem, and mount the file was in as well as its name, and various attributes such as owner, size, and modification time.

But to make something mildly useful to some people, just a filesystem option (probably simply the existence of the .trash directory in its root) would be reasonable.

I don't even think the per-file attribute would be useful in a system that simple -- I don't know how the designers of the system in question envision that getting set.

Does this not handle unsafe overwrites?

giraffedata — Fri, 08 Dec 2006 19:03:54 +0000

Right. What we want is secure de-allocation, not secure delete. That looks more like attaching deallocated blocks to a .trash file than linking unreferenced files to a .trash directory.

Secure deletion and trash bin support

niallm — Fri, 08 Dec 2006 15:48:18 +0000

It's the difference between un-deleteable and undelete-able.

Secure deletion and trash bin support

rwmj — Fri, 08 Dec 2006 14:27:50 +0000

The nicest file manager available will not be able do do anything about an "rm" command typed into a shell,[...]

Ummm, that's a feature, not a bug.

Rich.

Secure deletion and trash bin support

liljencrantz — Fri, 08 Dec 2006 01:37:57 +0000

I've read through all your complaints about trash, and as near as I can tell, they fall in two categories:

* Problems that are solved by the /UID/ indirection
* Problems that are solved by not changing the access permissions or ownership of the file when moving it to trash.

If I have missed any cases, please point them out to me.

Secure deletion and trash bin support

nix — Fri, 08 Dec 2006 01:16:31 +0000

Actually, the .uid stuff prevents some of these attacks.

Just some. Not all :/

Does this not handle unsafe overwrites?

nix — Fri, 08 Dec 2006 01:15:32 +0000

Yeah, I have a feeling this is yet *another* problem with this proposal.

I guess I should go and read the actual patch and moan on l-k if these
problems really do exist. (Still, I'm the last-ditch Viro Defence Force
would spot them if I didn't complain. I'm almost tempted not to moan
because Al's demolition is bound to be so much more amusing than any I
could come up with... ;) )

Secure deletion and trash bin support

nix — Fri, 08 Dec 2006 01:11:18 +0000

Great. I guess I'd better point out some of these DoS scenarios...

Given users a and b, in group C, where (all paths filesystem-relative):

/ is writable by user a, with the sticky bit on, and readable and
executable by everyone (of course).
/bar is writable by group C.
/baz is writable by user b only, and not readable by anyone else.
/foo is writable by user x, who is known to be a bit of a mischievous sod,
and not by user b.

User b deletes a file in /bar. Now presumably /.trash inherits its
permissions from /, right? Well, that file's just gone into /.trash, which
*b cannot delete files from*. So now user b can fill up the disk just by
creating and deleting files, but has to appeal to a to fix things.

Worse, files b delets in /baz can only be deleted from /.trash by user a,
even though user a *cannot delete them from /baz in the first place*.

But it gets nastier. What if user a deletes an important file and then
user x spots this and immediately afterwards deletes a file with the same
name from /foo? Does that file overwrite the important file in /.trash? Do
the files in /.trash get the directory name encoded in their filename
somehow, to evade this? (If so, that means you can break the system in
another way: the encoding for filenames must, if not ambiguous, sometimes
be longer than the filenames themselves. Thus it's possible to produce a
file in a deeply-nested directory which has a name which is too long, when
encoded, to be written to /.trash.)

Another scenario: user b deletes an important file out of /baz: it was
group-readable, but what the hell, it's in a directory they can't read
anyway. But now it's been deleted, that is no longer true: now user x can
read it. Worse, user x can hardlink it into his own directory, and b can't
do anything about it: can't even delete it again. However, it is possible
depending on the semantics of repeated deletion that he may be able to
*overwrite* it by deleting another file with the same name (in which case
deleting symlinks seems risky, as that's opened up an rm variant of the
classic symlink attack: delete a symlink to /etc/passwd, wait for root to
delete a file with the same name, oops: worse, an attacker with write
privs in /.trash can delete anyone's file by hardlinking it into /.trash
under a suitable name and waiting for someone to delete a suitable file:
no, overwriting is not safe, you must unlink()).

And then what happens if you flip on the immutable bit for files
in /.trash?

So now we have rm(1) not consistently trashing files, possibly leading to
unreadable-by-others files becoming readable by them and unremovable by
you, or alternatively leading to arbitrary files that happen to have
symlinks pointing to them or happen to have been hardlinked into or out
of /.trash being overwritten.

This proposal needs a *lot* of thought. Either /.trash is fantastically
magical and violates most Unix rules for file access (hardlinks out of and
into banned, *symlinks* out of and into banned, always 1777 except that
files belonging to other users don't appear, um, how will that work
exactly?) or you've opened a vast can of worms.

(A plan9-style per-user /.trash bind-mount might work better, but the
userspace infrastructure for that is not really there yet.)

Secure deletion and trash bin support

nix — Fri, 08 Dec 2006 00:54:03 +0000

This is, of course, not to be confused with the immutable attribute, which
(among other effects) makes a file un-deletable.

(gah.)

The trash directory thing has all sorts of horrible potential problems,
though, particularly when group- or world-writable directories are
concerned. (World-writable isn't common outside of /tmp, but
group-writable is common.)

I can see half a dozen ways to DoS the system with this alone, especially
if users can set attributes on the trash directory such that users can ask
to move files in there but then don't have privileges to delete them from
there...

Does this not handle unsafe overwrites?

droundy — Thu, 07 Dec 2006 23:22:03 +0000

It sounds like this patch doesn't handle the "secure" files in the case where their contents may be modified. In that case, the old contents could end up being left around on disk somewhere (e.g. if I run "echo > secure_file.txt"). Am I missing something, or is the patch missing something?

David

Secure deletion and trash bin support

jzbiciak — Thu, 07 Dec 2006 21:17:47 +0000

I'm saying that I might simply not want a .trash directory in a particular filesystem *ever*. For instance if I have an FS that I use for large temporary files, I don't think it should get a .trash, ever.

Secure deletion and trash bin support

oak — Thu, 07 Dec 2006 21:03:19 +0000

> I suppose it'll need to be a mount option in addition to a kernel
> feature.

Yes, there would need to be .trash dir for each file system...

Secure deletion and trash bin support

jzbiciak — Thu, 07 Dec 2006 20:32:59 +0000

I suppose it'll need to be a mount option in addition to a kernel feature. Even then I'm not sure it's perfect. For instance, what if /tmp isn't in its own filesystem?

Granted, it's a per-file attribute, so you have to remember to set it before you make a mistake anyway. Perhaps the attribute should be inherited from the current directory, one could set things up hierarchically? "I want undelete available in this tree, but not that one."

Secure deletion and trash bin support

bronson — Thu, 07 Dec 2006 18:31:32 +0000

I'm not a fan of undeleting in, say, /var. But in /home that would ROCK. They'd just have to give some thought to how to handle metrics (like, if I delete a file and my available disk space doesn't change, I'd be mighty confused).

I wish Joukov luck -- I really look forward to using this.

Secure deletion with journaling?

rvfh — Thu, 07 Dec 2006 16:52:50 +0000

The secure deletion resides in the FS part for sure. Only the undelete part can be in the VFS (just a mv after all).

Secure deletion with journaling?

zlynx — Thu, 07 Dec 2006 15:20:21 +0000

Overwrite the file with O_DIRECT set? Create a new filesystem flag so that even the most cache-happy journaled FS does the right thing?

Secure deletion with journaling?

abatters — Thu, 07 Dec 2006 15:04:46 +0000

According to the man page for 'shred', overwriting a file stored on a journaled filesystem (via normal write() system calls) does not necessarily overwrite the actual data on disk. I do not see how moving a deleted file to a special directory makes it possible to perform a subsequent secure delete if the VFS doesn't special-case it in other ways. This is especially true if the data had been written to blocks in the filesystem that are no longer associated with the file.

OTOH, the man page for chattr does mention a 'data journaling' attribute; maybe you are supposed to turn off data journaling at the same time as setting secure delete (preferably before writing any actual sensitive data to the file). Does anyone know if this flag is honored?

Secure deletion and trash bin support

Robin.Hill — Thu, 07 Dec 2006 14:24:06 +0000

Yes, the undeletable attribute means that the file can be undeleted. This is separate from the secure deletion attribute which means the file should be totally erased (and therefore not undeletable).

The initial step in this proposal is the same for both attributes - the file is moved to a trash directory. The user process will then check these files and, for those with the secure deletion flag set, erase them. Those with the undeletable attribute set will just be left in the trash directory (presumably trying to set both attributes will produce an error somewhere!).

Secure deletion and trash bin support

nix — Thu, 07 Dec 2006 10:36:59 +0000

Hm, actually, I think you may have been saying the same thing and I misread it. It really is *not* a very good name for an attribute...

Secure deletion and trash bin support

nix — Thu, 07 Dec 2006 10:36:05 +0000

My understanding was that the `undeletable' attribute led ext[23] to try to make the file easier to undelete: the opposite effect.

It's a rather bad name for an attribute, really :/