From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 22 02:54:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E51316A4CE; Sat, 22 Nov 2003 02:54:08 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC29943F85; Sat, 22 Nov 2003 02:54:06 -0800 (PST) (envelope-from se@freebsd.org) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng1.kundenserver.de with esmtp (Exim 3.35 #1) id 1ANVOu-0002lt-00; Sat, 22 Nov 2003 11:54:04 +0100 Received: from [80.132.228.43] (helo=Gatekeeper.FreeBSD.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1ANVOu-0006qy-00; Sat, 22 Nov 2003 11:54:04 +0100 Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id C168B5F18; Sat, 22 Nov 2003 11:54:00 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id 6CDE61EBC; Sat, 22 Nov 2003 11:54:00 +0100 (CET) Date: Sat, 22 Nov 2003 11:54:00 +0100 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20031122105400.GA4506@StefanEsser.FreeBSD.org> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <20031121124350.GT511@garage.freebsd.pl> <200311211333.39520.wes@softweyr.com> <20031121235607.GB16700@StefanEsser.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fa3fae9b6ca38d745862a668565919f6 cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2003 10:54:08 -0000 On 2003-11-22 11:04 +0100, Dag-Erling Sm=F8rgrav wrote: > Stefan E=DFer 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