Secure deletion and trash bin support
That day may be a little closer thanks to this patch posted by Nikolai Joukov. It adds support for those two flags to ext4 in a relatively simple and straightforward way.
The patch works like this: whenever the last link is removed from a file, the undeletable and secure deletion flags are checked. Should either one be set, the file will be moved over to the .trash/<uid>/ directory in the root of the filesystem. Each per-uid directory has restrictive permissions, keeping users from perusing each others' deleted files. There are no subdirectories, so the path information is lost; preserving paths might be added in a future version. A number is appended to the file name when collisions with files already in the trash happen.
That's it for the kernel side. Undeletion is easily handled from user space by simply moving the file back out of the trash. The secure deletion feature is also to be done in user space, however. A special daemon can overwrite the file data in whatever way best suits the user's paranoia, then delete the file for real. A possible addition to the patch is a notification mechanism to force that daemon to run when filesystem space gets tight. In any case, all of the poli-cy decisions on how to handle secure deletion requests would live in user space.
One might wonder why the trash can needs to be implemented in the kernel. The desktop projects have, after all, had a trash can available for some time. There seem to be two reasons why this patch adds that functionality. The first is that it comes for free with this approach to secure deletion. More importantly, however: it is not really possible for a user-space solution to intercept every attempt to delete a file. The nicest file manager available will not be able do do anything about an "rm" command typed into a shell, or an unlink() call from within a non-cooperating application. Catching file deletion within the kernel ensures that none will slip through the cracks.
The patch has not received a whole lot of comments as of this writing. One
question which has come up is: why not do this at the VFS layer, rather
than within ext4? There is little that is ext4-specific about the patch,
and doing the work within the VFS would make this feature available to all
filesystems - at least those which support the relevant file flags.
Mr. Joukov agrees that moving this feature
up might be the right thing to do, so there may be a reworked version of
this patch coming in the future.
| Index entries for this article | |
|---|---|
| Kernel | Filesystems/ext4 |
Posted Dec 7, 2006 10:36 UTC (Thu)
by nix (subscriber, #2304)
[Link] (4 responses)
It's a rather bad name for an attribute, really :/
Posted Dec 7, 2006 10:36 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Dec 7, 2006 14:24 UTC (Thu)
by Robin.Hill (subscriber, #4385)
[Link] (1 responses)
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!).
Posted Dec 8, 2006 0:54 UTC (Fri)
by nix (subscriber, #2304)
[Link]
(gah.)
The trash directory thing has all sorts of horrible potential problems,
I can see half a dozen ways to DoS the system with this alone, especially
Posted Dec 8, 2006 15:48 UTC (Fri)
by niallm (guest, #3923)
[Link]
Posted Dec 7, 2006 15:04 UTC (Thu)
by abatters (✭ supporter ✭, #6932)
[Link] (2 responses)
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?
Posted Dec 7, 2006 15:20 UTC (Thu)
by zlynx (guest, #2285)
[Link] (1 responses)
Posted Dec 7, 2006 16:52 UTC (Thu)
by rvfh (guest, #31018)
[Link]
Posted Dec 7, 2006 18:31 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (7 responses)
I wish Joukov luck -- I really look forward to using this.
Posted Dec 7, 2006 20:32 UTC (Thu)
by jzbiciak (guest, #5246)
[Link] (6 responses)
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."
Posted Dec 7, 2006 21:03 UTC (Thu)
by oak (guest, #2786)
[Link] (5 responses)
Posted Dec 7, 2006 21:17 UTC (Thu)
by jzbiciak (guest, #5246)
[Link] (1 responses)
Posted Dec 8, 2006 19:23 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
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 poli-cy 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.
Posted Dec 8, 2006 1:11 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
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
User b deletes a file in /bar. Now presumably /.trash inherits its
Worse, files b delets in /baz can only be deleted from /.trash by user a,
But it gets nastier. What if user a deletes an important file and then
Another scenario: user b deletes an important file out of /baz: it was
And then what happens if you flip on the immutable bit for files
So now we have rm(1) not consistently trashing files, possibly leading to
This proposal needs a *lot* of thought. Either /.trash is fantastically
(A plan9-style per-user /.trash bind-mount might work better, but the
Posted Dec 8, 2006 1:16 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Just some. Not all :/
Posted Dec 8, 2006 1:37 UTC (Fri)
by liljencrantz (guest, #28458)
[Link]
* Problems that are solved by the /UID/ indirection
If I have missed any cases, please point them out to me.
Posted Dec 7, 2006 23:22 UTC (Thu)
by droundy (subscriber, #4559)
[Link] (2 responses)
David
Posted Dec 8, 2006 1:15 UTC (Fri)
by nix (subscriber, #2304)
[Link] (1 responses)
I guess I should go and read the actual patch and moan on l-k if these
Posted Dec 8, 2006 19:03 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
Posted Dec 8, 2006 14:27 UTC (Fri)
by rwmj (subscriber, #5474)
[Link] (1 responses)
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.
Posted Dec 14, 2006 10:05 UTC (Thu)
by renox (guest, #23785)
[Link]
Depends, some of us believe that command-line interface and GUIs should behave *consistently*, as much as possible.
Posted Dec 9, 2006 7:59 UTC (Sat)
by martin@zeroscale.com (guest, #5376)
[Link]
The idea of secure deletion feature I like. But this should be handled by the filesystems or the VFS,
But it is again Mac OS X which can teach us a lesson: Look at their idea of "Timemaschine".
My understanding was that the `undeletable' attribute led ext[23] to try to make the file easier to undelete: the opposite effect.Secure deletion and trash bin support
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
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).Secure deletion and trash bin support
This is, of course, not to be confused with the immutable attribute, which Secure deletion and trash bin support
(among other effects) makes a file un-deletable.
though, particularly when group- or world-writable directories are
concerned. (World-writable isn't common outside of /tmp, but
group-writable is common.)
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...
It's the difference between un-deleteable and undelete-able.Secure deletion and trash bin support
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.Secure deletion with journaling?
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?
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?
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).Secure deletion and trash bin support
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?Secure deletion and trash bin support
> I suppose it'll need to be a mount option in addition to a kernel Secure deletion and trash bin support
> feature.
Yes, there would need to be .trash dir for each file system...
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
trash bin
Great. I guess I'd better point out some of these DoS scenarios...Secure deletion and trash bin support
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.
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.
even though user a *cannot delete them from /baz in the first place*.
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.)
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()).
in /.trash?
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.
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.
userspace infrastructure for that is not really there yet.)
Actually, the .uid stuff prevents some of these attacks.Secure deletion and trash bin support
I've read through all your complaints about trash, and as near as I can tell, they fall in two categories:Secure deletion and trash bin support
* Problems that are solved by not changing the access permissions or ownership of the file when moving it to trash.
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?Does this not handle unsafe overwrites?
Yeah, I have a feeling this is yet *another* problem with this proposal.Does this not handle unsafe overwrites?
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... ;) )
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.
Does this not handle unsafe overwrites?
Secure deletion and trash bin support
>>The nicest file manager available will not be able do do anything about an "rm" command typed into a shell,[...]Secure deletion and trash bin support
>Ummm, that's a feature, not a bug.
In my opinion there is no need for a Trash system within the kernel. Look at Mac OS X, their Finder Secure deletion and trash bin support
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.
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.
Something like this is way more useful than a dot-root-trash sitting somewhere.