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>