Date: Fri, 21 Nov 2003 14:09:18 -0800 From: Wes Peters <wes@softweyr.com> To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=), Pawel Jakub Dawidek <nick@garage.freebsd.pl> Cc: Rayson Ho <raysonlogin@yahoo.com> Subject: Re: "secure" file flag? Message-ID: <200311211333.39520.wes@softweyr.com> In-Reply-To: <xzpsmkhyhlr.fsf@dwp.des.no> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <20031121124350.GT511@garage.freebsd.pl> <xzpsmkhyhlr.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 21 November 2003 05:30, Dag-Erling Sm=F8rgrav wrote: > Pawel Jakub Dawidek <nick@garage.freebsd.pl> writes: > > I'm aware of this, but what we want to think over here is something > > like in-kernel 'rm -P'. So file will be overwriten even if it is > > opened and/or link count is grater than 0. > > That is not acceptable. First of all, it breaks a lot of assumptions > in the filesystem code. Second, it is incompatible with the common > technique of unlinking a temporary file immediately after opening it > to avoid having it stick around if the process that created it dies > prematurely. Your proposed change would thus reduce security rather > than enhance it. Right. The idea of restricting a file marked "secure" to not be able to=20 link to it, and refusing to set the flag if the file has a link count=20 greater than 1, is easy to do. I'm not sure it makes sense, though. > Besides, overwriting the contents of a file when it is removed from > the file system is not enough. You also need to overwrite every > block or fragment which is released any time the file shrinks. > > Fortunately, ufs always truncates a file to length 0 when it is > removed, so you only need to modify ffs_truncate() to implement both > aspects (truncation and removal). You should also take care to > overwrite the file's extended attributes if it has any. =46or ffs, I believe it would be as simple as providing this behavior in=20 ffs_blkfree. Both the vnode and fs are passed to ffs_blkfree, so the=20 code should be able to check filesystem flags and/or file flags to=20 determine if the block should be erased before freed. This simplistic=20 approach would forgo some potentially very helpful optimizations,=20 though. > Finally, I think a filesystem flag is much better for this purpose > than a file flag; and in either case, file removal and truncation > performance will be awful. The filesystem flag is no more or less difficult to do; I can see doing=20 both for completeness sake. As for performance, you really need to flush the on-device cache on each=20 pass to make sure the bit patterns get written to the platter in proper=20 order. I don't see any clever way to coalesce the writing of the=20 various patterns to multiple blocks short of a kernel thread, either,=20 so performance would be abysmal. Imagine removing a large file,=20 overwriting each block in 37 (IIRC) passes, syncing all the way through=20 the on-disk cache after *every block.* Disk encryption suddenly doesn't look so bad, does it? =2D-=20 "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311211333.39520.wes>