From owner-freebsd-security Fri Jun 25 17:49: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [130.126.8.20]) by hub.freebsd.org (Postfix) with ESMTP id C0D2014D3D for ; Fri, 25 Jun 1999 17:49:01 -0700 (PDT) (envelope-from igor@alecto.physics.uiuc.edu) Received: (from igor@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) id TAA10675 for freebsd-security@freebsd.org; Fri, 25 Jun 1999 19:49:00 -0500 (CDT) From: Igor Roshchin Message-Id: <199906260049.TAA10675@alecto.physics.uiuc.edu> Subject: Re: Secure Deletion In-Reply-To: from "Nicholas Brawn" at "Jun 26, 1999 10:26:37 am" To: freebsd-security@freebsd.org Date: Fri, 25 Jun 1999 19:49:00 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 > Should not it be this way: if the user is not allowed "cryptographically" to see the directory (obviously, it would not be /tmp !), then, certainly that user should be prohibited from writing in it (as well, as any other type of access) by the same means. So, if I am not authorized to see the directory ~ncb/ , I should be able to write in it, and, most likely in any of its subdirectories. May be I am missing something ? Igor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message