From owner-freebsd-security Fri Oct 17 11:17:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA27577 for security-outgoing; Fri, 17 Oct 1997 11:17:36 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA27570 for ; Fri, 17 Oct 1997 11:17:33 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id LAA00238; Fri, 17 Oct 1997 11:17:19 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd000235; Fri Oct 17 11:17:13 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id LAA16458; Fri, 17 Oct 1997 11:17:10 -0700 (MST) From: Terry Lambert Message-Id: <199710171817.LAA16458@usr06.primenet.com> Subject: Re: C2 Trusted FreeBSD? To: cdillon@tri-lakes.net (Chris Dillon) Date: Fri, 17 Oct 1997 18:17:10 +0000 (GMT) Cc: narvi@haldjas.folklore.ee, tlambert@primenet.com, security@FreeBSD.ORG, benedict@echonyc.com In-Reply-To: from "Chris Dillon" at Oct 15, 97 09:22:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >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? > > Not my area of expertise exactly, but from what I gather, yes. This would > eat tremendous amounts of precious I/O, unless I suppose it was done at > idle times, but that might defeat the purpose of it. This should be done on a block by block basis, and could be done in a stacking layer on top of a variable granularity block store. This assumes that the bottom end of the VFS (the VM interface) is ever standardized between FS's (right now each local media FS has OS specific VM code), and that stacking is fixed. I've been seriously looking at variable granularity block stores for several (6) years now, with an eye towards supporting concurrent cluster, extent, and record based filing, all in one implementation; sort of a meta-FS implementation. It has implications for things like attribution, directory hierarchy imposition, access control lists, trustee rights, etc.. In truth, it's my "holy grail", as far as FS technology is concerned, and it's the end goal of all the FS architecture changes I've been pushing (basically, to simply enable me to do the necessary research, without compromising the ability of other people to also do their own thing -- it takes a big frame to be able to cut it down to fram any picture). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.