evins@nrl-radar.arpa (Jim Evins) (05/18/87)
Hi, Does anyone know of a version of rm that allows you to scrub blocks clean before making them available, for BSD VAXes and Suns. This would allow non-secure systems to go secure, and receive transient confidential data, without having to scrub the entire disk when returning to non-secure mode. I realize there are probably a lot of issues involved. I would appreciate any leads. Thanks. -Jim Evins <evins@nrl-radar.arpa>
ark@alice.UUCP (05/19/87)
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.
dpw@unisec.UUCP (05/20/87)
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. -- Darryl Wagoner UniSecure Systems, Inc.; dpw@unisec.usi.com Newport, RI; (401)-849-0857 UUCP: {gatech|mirror|cbosgd|uiucdcs|ihnp4}!rayssd!unisec!dpw
hank@spook.UUCP (Hank Cohen) (05/21/87)
>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
todd@uhccux.UUCP (The Perplexed Wiz) (05/22/87)
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. I don't have to deal with such issues as scrubbing disks for security anymore. But back when I did, I seem to recall that gov't sites had a few rules as to exactly what was considered a clean disk for security purposes. You might want to check with your organization's security people before you start spending time writing file scrubbing code....todd -- Todd Ogasawara, U. of Hawaii Computing Center UUCP: {ihnp4,seismo,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!todd ARPA: uhccux!todd@nosc.MIL INTERNET: todd@uhccux.UHCC.HAWAII.EDU
rcodi@yabbie.UUCP (05/22/87)
In article <520@unisec.usi.com>, dpw@unisec.usi.com (Darryl P. Wagoner) writes: > 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. Also, if the file was a random file (ie: may have holes in it), you could easily run out of disk space whilst writing trash into it unless you only wrote trash into blocks that read as non-zero (ie: those blocks that were never allocated but are below the file size). A kernel implementation could do that much more efficiently, since it knows where the holes are. Ian D.