From owner-freebsd-security  Wed Oct 15 15:08:45 1997
Return-Path: <owner-freebsd-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA11387
          for security-outgoing; Wed, 15 Oct 1997 15:08:45 -0700 (PDT)
          (envelope-from owner-freebsd-security)
Received: from stt3.com (root@stt3.com [198.107.49.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA11369
          for <security@FreeBSD.ORG>; Wed, 15 Oct 1997 15:08:39 -0700 (PDT)
          (envelope-from beattie@stt3.com)
Received: from durin(really [192.168.0.88]) by stt3.com
	via sendmail with smtp
	id <m0xLbbP-00008vC@stt3.com>
	for <security@FreeBSD.ORG>; Wed, 15 Oct 1997 15:07:39 -0700 (PDT)
	(Smail-3.2 1996-Jul-4 #1 built 1997-Mar-5)
Date: Wed, 15 Oct 1997 15:07:38 -0700 (PDT)
From: Brian Beattie <beattie@stt3.com>
X-Sender: beattie@durin
To: Narvi <narvi@haldjas.folklore.ee>
cc: benedict@echonyc.com, security@FreeBSD.ORG,
        Terry Lambert <tlambert@primenet.com>
Subject: Re: C2 Trusted FreeBSD?
In-Reply-To: <Pine.BSF.3.96.971015093743.9017C-100000@haldjas.folklore.ee>
Message-ID: <Pine.GSO.3.95.971015150134.4841A-100000@durin>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-security@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, 15 Oct 1997, Narvi wrote:

> 
> On Wed, 15 Oct 1997, Snob Art Genre wrote:
> 
> > On Tue, 14 Oct 1997, Chris Dillon wrote:
> > 
> > <snip>
> > > The point is, if someone stole your SIMMs out of your BOX to try and steal
> > > data from them, they're out of luck.. If they steal what you THINK is a
> > > totally blank hard drive or floppy disk that you previously wrote
> > > sensitive data to, think again.  This is why it is standard policy in some
> > > places for drives that went south to not just be thrown away, but
> > > completely destroyed with a sledge-hammer. :-)
> > 
> 
> Or in other words - C2 or not, we are going to need a modified ffs that
> properly overwrites the freed (via unlink, truncate or other means)
> storage on disk anyways?
> 

You only need this if you do not have physical security.  If you do not
have physicial security, you do not have security.  Overwriting freed disk
blocks is not needed at B3, nor do I think at A1.  In truly secure
environments disks, never leave.  In slightly less secure environments,
there are utilities to overwrite all the bits so a disk can be removed
from the secure environment.

Overwritting freed resources as a standard procedure is never needed.