Weekly Edition
Return to the Kernel page
| |||||||||||||
Secure deletion and trash bin support
A look at the man page for the chattr command reveals some
interesting functionality; users may set special bits on files to request
either that the file be undeletable, or that deletion be "secure" - meaning
that the file's contents truly disappear from the disk. The key word here,
however, is "request." Those bits have existed for many years, but few -
if any - Linux filesystems actually implement those features. The
undeletable and secure deletion flags are just placeholders for a "would be
nice" feature to be added in the future. Someday.
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 policy 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. (Log in to post comments)
Secure deletion and trash bin support Posted Dec 7, 2006 10:36 UTC (Thu) by nix (subscriber, #2304) [Link] 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 :/
Secure deletion and trash bin support Posted Dec 7, 2006 10:36 UTC (Thu) by nix (subscriber, #2304) [Link] 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 Posted Dec 7, 2006 14:24 UTC (Thu) by Robin.Hill (subscriber, #4385) [Link] 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 Posted Dec 8, 2006 0:54 UTC (Fri) by nix (subscriber, #2304) [Link] 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,
I can see half a dozen ways to DoS the system with this alone, especially
Secure deletion and trash bin support Posted Dec 8, 2006 15:48 UTC (Fri) by niallm (guest, #3923) [Link] It's the difference between un-deleteable and undelete-able.
Secure deletion with journaling? Posted Dec 7, 2006 15:04 UTC (Thu) by abatters (✭ supporter ✭, #6932) [Link] 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 with journaling? Posted Dec 7, 2006 15:20 UTC (Thu) by zlynx (subscriber, #2285) [Link] 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? Posted Dec 7, 2006 16:52 UTC (Thu) by rvfh (subscriber, #31018) [Link] 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 and trash bin support Posted Dec 7, 2006 18:31 UTC (Thu) by bronson (subscriber, #4806) [Link] 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 and trash bin support Posted Dec 7, 2006 20:32 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] 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 Posted Dec 7, 2006 21:03 UTC (Thu) by oak (guest, #2786) [Link] > 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 Posted Dec 7, 2006 21:17 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] 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.
trash bin Posted Dec 8, 2006 19:23 UTC (Fri) by giraffedata (subscriber, #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 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.
Secure deletion and trash bin support Posted Dec 8, 2006 1:11 UTC (Fri) by nix (subscriber, #2304) [Link] 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
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
Secure deletion and trash bin support Posted Dec 8, 2006 1:16 UTC (Fri) by nix (subscriber, #2304) [Link] Actually, the .uid stuff prevents some of these attacks.
Just some. Not all :/
Secure deletion and trash bin support Posted Dec 8, 2006 1:37 UTC (Fri) by liljencrantz (guest, #28458) [Link] 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
If I have missed any cases, please point them out to me.
Does this not handle unsafe overwrites? Posted Dec 7, 2006 23:22 UTC (Thu) by droundy (subscriber, #4559) [Link] 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
Does this not handle unsafe overwrites? Posted Dec 8, 2006 1:15 UTC (Fri) by nix (subscriber, #2304) [Link] 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
Does this not handle unsafe overwrites? Posted Dec 8, 2006 19:03 UTC (Fri) by giraffedata (subscriber, #1954) [Link] 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 Posted Dec 8, 2006 14:27 UTC (Fri) by rwmj (subscriber, #5474) [Link] 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 Posted Dec 14, 2006 10:05 UTC (Thu) by renox (subscriber, #23785) [Link] >>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 Posted Dec 9, 2006 7:59 UTC (Sat) by martin@zeroscale.com (guest, #5376) [Link] In my opinion there is no need for a Trash system within the kernel. Look at Mac OS X, their Finderapplication 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,
But it is again Mac OS X which can teach us a lesson: Look at their idea of "Timemaschine".
|
|||||||||||||