Messages in this thread |  | | | Date | Fri, 24 Jul 1998 08:53:19 -0400 (EDT) | | From | "Richard B. Johnson" <> | | Subject | Re: Secure deletion |
| |
On Thu, 23 Jul 1998, Jeffrey B. Siegal wrote:
> Richard B. Johnson wrote: > > > Suppose you modified the 'C' runtime library so it could be recompiled with > > a switch that changes anything that 'removes' files to: > > > > stat the file (to get length); > > write the file with junk. > > close the file. > > sync the file-system. > > unlink the file. > > sync the file-system. > > > > For one thing, it isn't atomic. If the length of the file increases after the > stat, the extra blocks won't be cleared. This could be detected by adding another > stat after the clearing (and a loop if necessary), but the length of the file could > temporarily increase, and then decrease. Only the kernel can do this atomically. > > > The problem with doing this in the kernel is that any time anything > > removes a file, you have to flush buffers to disk to make sure that > > the new data gets to the physical media. This will slow the file-system > > to a crawl. > > Remember, not every application is particularly performance sensitive. I'd be > willing to accept poor performance for increased security *for certain > applications*.
As others have mentioned 'security' comes in many flavors. If you want to reduce the possibility of having someone read something that they should not, to something very small, just fill up your disk(s) every night with a file that contains junk, sync the file-system, then delete the file.
If you have users who run programs in loops, trying to read something they don't "own", then you need atomic, in kernel, stuff to prevent this. The easiest way to prevent this is to use a properly-loaded '357, although the may be frowned upon in some circles.
FYI, here is a program I use. It runs every night on my most-abused file-server that has 40 interactive users, all hackers. Most have PPP links from home through this system so they can try to do whatever they try to do, without any chance of getting caught.
If you create a file with holes, or play other games to try to read data you didn't create, your chances are not very great of reading anything but "SECURITY ". Try it.
Cheers, Dick Johnson ***** FILE SYSTEM MODIFIED ***** Penguin : Linux version 2.1.108 on an i586 machine (66.15 BogoMips). Warning : It's hard to remain at the trailing edge of technology./* * Free software to write a security pattern over deleted file-space * in the wee hours of the night. * cron usage: * security /filename * security /home/filename * security /tmp/filename * * This writes a file large enough to fill up the disk partition, * syncs the file-system, then deletes the file. * Created 20-JUL-1998 rjohnson@analogic.com. * No Copyright is claimed and there is no warranty. */
#include <stdio.h> #include <unistd.h> #include <stdlib.h> #include <fcntl.h> #include <string.h> #include <errno.h> #define BUF_LEN 0x1000 #define FILENAME argv[1] #define WHO argv[0] #define LEN (sizeof(secur) -1) const char secur[]="SECURITY "; int main(int args, char *argv[]) { int fd, i; char *buffer; char *p; if(args < 2) { fprintf(stderr, "Usage:\n"); fprintf(stderr, "%s pathname\n", argv[0]); exit(EXIT_FAILURE); } if((fd = open(FILENAME, O_RDWR|O_CREAT, 0644)) < 0) { fprintf(stderr, "From %s, file creation error %s\n", WHO, strerror(errno)); } if((buffer = (char *) malloc(BUF_LEN *sizeof(char))) == NULL) { (void)close(fd); (void)unlink(FILENAME); fprintf(stderr, "From %s, can't allocate memory\n", WHO); exit(EXIT_FAILURE); } p = buffer; for(i=0; i< BUF_LEN / LEN; i++) { memcpy(p, secur, LEN); p += LEN; } for(;;) { if(write(fd, buffer, BUF_LEN) != BUF_LEN) break; } (void)close(fd); (void)sync(); free(buffer); (void)sleep(10); (void)unlink(FILENAME); return EXIT_SUCCESS; }
|  |