Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!epiwrl!spook!hank
From: hank@spook.UUCP (Hank Cohen)
Newsgroups: comp.unix.wizards
Subject: Re: rm with a block scrub
Message-ID: <108@spook.UUCP>
Date: Thu, 21-May-87 12:05:21 EDT
Article-I.D.: spook.108
Posted: Thu May 21 12:05:21 1987
Date-Received: Sat, 23-May-87 14:59:40 EDT
References: <7421@brl-adm.ARPA> <6899@alice.UUCP> <520@unisec.usi.com>
Reply-To: hank@masscomp.UUCP (Hank Cohen)
Organization: MASSCOMP -- Bethesda Md.
Lines: 33
Keywords: security
Summary: The kernel already does it.

>In article <6899@alice.UUCP> ark@alice.UUCP writes:
>In article <7421@brl-adm.ARPA>, evins@nrl-radar.arpa writes:
>>> 	Does anyone know of a version of rm that allows you to scrub blocks
>>> clean before making them available, for BSD VAXes and Suns.
>
>>Before you unlink the file, open it for output and write a block
>>of zeroes over every block of the file.  Then sync() and unlink it.
>
>Before you go out "scrubbing" the file with zeros make sure it is the
>last link or you will find yourself with a file that has been
>wiped clean.  Could have some very bad results if it was say, ptmp.


You should probably check with your security people to see if this is
really necessary.  A special version of rm will not solve the problem
since any program can deallocate file system blocks by truncating or
unlinking a file.  The object of this exercise is usually to insure
that no user can access information that they are not authorized to
see.  On our systems and I suspect on most Unix systems when the user
gains read access to an I/O buffer, by address mapping or a read
request the block is zeroed before the user can see it.  So createing
a file and reading uninitialized blocks should always return nulls.
I assume that you are already careful about file and device modes and such. 
The real problem is if the system is going to be declassified or the
disk removed.  Then the whole disk generally has to be scrubbed.  
Many formatters do this when doing bad block checking but the DOD at 
least has specific requirements for the patterns written to the raw disk.

Hank Cohen 
MASSCOMP 
7315 Wisconsin Ave. Suite 1245W
Bethesda Md. 20814
(301) 657-9855