From owner-freebsd-security Sun Oct 28 11:57: 9 2001 Delivered-To: freebsd-security@freebsd.org Received: from athena.za.net (athena.za.net [196.30.167.200]) by hub.freebsd.org (Postfix) with ESMTP id BF49737B408 for ; Sun, 28 Oct 2001 11:57:01 -0800 (PST) Received: from jus (helo=localhost) by athena.za.net with local-esmtp (Exim 3.22 #1) id 15xw26-0004AS-00; Sun, 28 Oct 2001 21:55:46 +0200 Date: Sun, 28 Oct 2001 21:55:46 +0200 (SAST) From: Justin Stanford X-Sender: jus@athena.za.net To: Peter Jeremy Cc: Sheldon Hearn , Martijn Lina , Thomas Beauchamp , freebsd-security@FreeBSD.ORG Subject: Re: recovery from 'rm -rf /' In-Reply-To: <20011029065239.F75481@gsmx07.alcatel.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I can report recent successful use of TCT (The Coroner's Toolkit, a set of forensic data tools) on a FreeBSD 4.4-STABLE system with soft updates, on a rm -rf * in my ~. I'm still busy working through all of the Lazarus output (There was around 3 gigs worth of free space on the partition) but so far I have had several successful hits. Regards, Justin -- Justin Stanford Internet/Network Security & Solutions Consultant 4D Digital Security http://www.4dds.co.za Cell: (082) 7402741 E-Mail: jus@security.za.net PGP Key: http://www.security.za.net/jus-pgp-key.txt On Mon, 29 Oct 2001, Peter Jeremy wrote: > On Thu, Oct 04, 2001 at 01:03:26PM +0200, Sheldon Hearn wrote: > > > > > >On Wed, 03 Oct 2001 22:30:38 +0200, Martijn Lina wrote: > > > >> first of all, be sure that absolutely nothing is writing to the disk > >> anymore. the inodes that have been freed last, will be the first to be > >> used again. > > > >Are you sure about that? > > Prior to FFS, freed disk blocks went into a LIFO list so the last > freed block would be the first allocated. A limited number (~100) of > freed inodes are cached in the super-block (further freed inodes were > just released). This means that new inodes would be allocated from > roughly the 100 first deleted files in reverse order (additional > inodes would be be allocated by searching the inode list for free > inodes). > > With FFS, I'm not so certain. The following is based on a quick study > of /sys/ufs/ffs/ffs_alloc.c - a FS guru might like to confirm it. The > last freed inode may possibly be the first re-allocated inode (it's > not immediately clear to me). Further inodes are allocated by a > mixture of searching linearly through the free inode bitmap in a > cylinder group and hashing between CGs. Likewise, the last release > block may be cached, but further blocks are allocated by searching as > before (potentially modified by rotational position). Soft-updates > further confuses the issue - the dependency graph and write-behind > means that the most-recently deleted file (blocks or inode) won't be > available for immediate re-allocation. > > That said, avoiding writing anything to disk is good advice. If the > other filesystems are clean and the mistake is noticed quickly, I'd > even suggest using the reset button to avoid the sync-on-unmount > (and not fsck'ing that filesystem after rebooting). > > Peter > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message