Date: Fri, 21 May 1999 20:14:00 -0600 From: Warner Losh <imp@harmony.village.org> To: Charles <charlesiii@theverge.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: secure deletion Message-ID: <199905220214.UAA00358@harmony.village.org> In-Reply-To: Your message of "Fri, 21 May 1999 22:03:27 -0300." <Pine.LNX.4.10.9905212202110.31903-100000@theverge.com> References: <Pine.LNX.4.10.9905212202110.31903-100000@theverge.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.LNX.4.10.9905212202110.31903-100000@theverge.com> Charles writes: : If your data is that important what are you doing on a network : in the first place eh? I can see an excellent use for this technology. First, I'd like to see an option that will turn this on for all files in a file system. The reason for doing that is because I'd like to turn it on my /tmp partition so that any temp files are killed dead. Many mail programs/readers/etc will write to /tmp. Most are good enough to open the file and immediately unlink it (however, since it is still open, the data still may wind up on disk). This, btw, is one reason why modifying unlink in libc in insufficient. I know this would be a performance hit, but I do not care. I can also see setting this bit for a directory as well. Since I use mh for my email, when i do an inc, I get lots of files in one directory. When this bit is set in the directory, then when a file is deleted, it is shredded completely. I do not want to have to set bits on all my mail. The mail that I get might contain sensitive information that I do not wish to have disclosed to anybody should my machine be siezed before those disks blocks can be reused. Another reason for placing it into the kernel has been stated before. Namely that if a file grows, then the fragment that was previously in use at the end of the file needs to be shredded. It all depends on what level you want to be paranoid. I can certainly understand the desire for people to run with this feature for a normal, production system. A mail relay system, for example, would be an excellent candidate. That system is potentially exposed to the outside world. With a shredding option in place, it becomes impossible for an intruder to gain access to snippets of email from prior days that were spinning on the disk unallocated. While there is still a lot that an intruder can do on that system, you have a very very very high level of assurance that he/she/it didn't get information that predates the penetration, save what was in the mail queues. Without this, you have no such assurances. While it is true that the intruder can do damage after the penetration, or steal data that flows through the machine after such a penetration, most detection procedures will detect this intrusion. Finally, networks are a way of life for many people. I cannot control what people send me over the network. Most of the sensitive information does come to me encrypted, but I want protection for the stuff that isn't. To assume that just because a machine is on the network it contains no interesting data (or that it can contain no interesting data) is not a valid assumption. The suggestion of removing the machine from the network is unhelpful. Just trying to present a reasonable view about why someone would want to use this feature, and some design parameters that would maximize its usefulness. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905220214.UAA00358>