Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-adm!brl-smoke!smoke!Makey@LOGICON.ARPA From: Makey@LOGICON.ARPA (Jeff Makey) Newsgroups: net.sources.bugs Subject: Re: What happens during an unlink(2) Message-ID: <738@brl-smoke.ARPA> Date: Fri, 9-May-86 21:19:02 EDT Article-I.D.: brl-smok.738 Posted: Fri May 9 21:19:02 1986 Date-Received: Sun, 25-May-86 06:29:53 EDT Sender: news@brl-smoke.ARPA Lines: 27 Seen in article <438@ukecc.UUCP> by "Edward C. Bennett" : >In article <238@chronon.chronon.UUCP>, eric@chronon.UUCP (Eric Black) writes: >> > >> > [discussion of what unlink(2) does] >> >> Some unitory systems do, indeed, zero out disk blocks when de-allocated, >> and similarly clear memory when freed. Any system you sell to customers >> with concerns about security will require this. Check out DOD requirements >> for secure systems in the "Department of Defense Trusted Computer >> System Evaluation Criteria", publication CSC-STD-001-83 (my copy is >> dated March 1985) for this and other interesting features... To prevent any misconceptions, it should be noted that CSC-STD-001-83 does not specifically require disk space or memory to be cleared when freed, or when allocated, or that it be written to before you read from it. However, unless the system in question enforces at least *one* of these strategies it will most likely fail CSC-STD-001-83's "Object Reuse" requirement. :: Jeff Makey Makey@LOGICON.ARPA P.S. Copies of CSC-STD-001-83 dated March 1985 can be considered collector's items. That cover date is a misprint and only a few hundred of them were distributed. The only correct cover date is 15 August 1983.