Date: Sat, 22 Nov 2003 11:54:00 +0100 From: Stefan =?iso-8859-1?Q?E=DFer?= <se@FreeBSD.org> To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no> Cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? Message-ID: <20031122105400.GA4506@StefanEsser.FreeBSD.org> In-Reply-To: <xzpzneosor3.fsf@dwp.des.no> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <20031121124350.GT511@garage.freebsd.pl> <xzpsmkhyhlr.fsf@dwp.des.no> <200311211333.39520.wes@softweyr.com> <20031121235607.GB16700@StefanEsser.FreeBSD.org> <xzpzneosor3.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2003-11-22 11:04 +0100, Dag-Erling Sm=F8rgrav <des@des.no> wrote: > Stefan E=DFer <se@FreeBSD.org> writes: > > I may be way off, but I do not think, that a special thread or=20 > > a cache flush after each block is required: [...] >=20 > What happens if you yank the power cord? Worst case: The same thing that happened, if the you lost power a fraction of a second earlier, just before the unlink or loss of last reference to the file ... Nothing short of a self-destruct mechanism will do any better ;-) (You could provide an internal UPS and try to prevent unauthorized access to hardware components by sealing the components in a special enclosing, but I guess we are getting carried away. Better protect against unauthorized access to the computer and have it emergency shutdown (with secure deletion of critical information) in case of a (physical :) access violation. Back to the subject of this thread: You could write a special flag "needs to be securely removed" to the inode. That way, an interrupted overwrite process could be=20 continued after next reboot (for example initiated by fsck). This is meant to protect against traces of sensible data being left on the disk for a long time after a crash. But such an inode would also indicate to an attacker the disk blocks that where considered needing protection and may make an attack at the magnetic residue practical=20 at all ... But the real problem appears to be, when to mark the blocks and=20 inode as free. Normally, the blocks are returned to the free block=20 map when an inode is invalidated. File system blocks may not be=20 reused, before the overwrite procedure has completed. Again, this requires that the inode is only removed after the last=20 file block has been processed. But I'm not sure whether there is=20 a mechanism that allows invalidating the inode after the last=20 associated buffer has been flushed ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031122105400.GA4506>