From owner-freebsd-security Fri Jun 25 17:27:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from zip.com.au (zipper.zip.com.au [203.12.97.1]) by hub.freebsd.org (Postfix) with ESMTP id 629C914D3D for ; Fri, 25 Jun 1999 17:27:00 -0700 (PDT) (envelope-from ncb@zip.com.au) Received: from localhost (ncb@localhost) by zip.com.au (8.9.1/8.9.1) with ESMTP id KAA25508; Sat, 26 Jun 1999 10:26:39 +1000 Date: Sat, 26 Jun 1999 10:26:37 +1000 (EST) From: Nicholas Brawn To: Robert Watson Cc: Jason Young , cjclark@home.com, freebsd-security@FreeBSD.ORG Subject: Re: Secure Deletion In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 25 Jun 1999, Robert Watson wrote: > > > On a related noted, Ross Anderson and others wrote a paper on > steganographic file systems > > http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/sfs3.ps.gz > > That is, file systems intended to hide even the presence of files if the > user is not authorized, cryptographically. Ross has suggested I port the > linux code to FreeBSD while I'm at Cambridge for the next few weeks. > Given the backlog of Posix.1e stuff, I may not get around to it, but it's > an interesting concept. I pondered a similar idea a while back. However I was curious of how to address a situation like the following: user 'a' creates "myfile" in /tmp. user 'b' is perusing /tmp, and decides to create a file called "myfile". What is the response at this stage? Does the OS tell 'b' that their permission is denied, resulting in a potential for bruteforcing the existance of hidden files? Alternatively, you could allow 'b' to create "myfile", and have a psuedo file system that is only makes files created available to owners of the file, but allowing multiple occurences of "myfile" to exist in the same logical file system. But then you'd have to think about how you could make files available to others. Nick > > It does bring up the issue of meta-data, however. Probably, disk sectors > should be marked as needing real wiping, and inodes + directory entries > need to be similarly treated after file deletion. (this in FreeBSD-land > again, not the SFS). > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > > Carnegie Mellon University http://www.cmu.edu/ > TIS Labs at Network Associates, Inc. http://www.tis.com/ > Safeport Network Services http://www.safeport.com/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message