lkml.org 
[lkml]   [1998]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateFri, 24 Jul 1998 08:53:19 -0400 (EDT)
From"Richard B. Johnson" <>
SubjectRe: 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;
}

\
 
 \ /
  Last update: 2005-03-22 13:43    [from the cache]
©2003-2010