Date: Sun, 28 Oct 2001 21:55:46 +0200 (SAST) From: Justin Stanford <jus@security.za.net> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: Sheldon Hearn <sheldonh@starjuice.net>, Martijn Lina <martijn@medialab.lostboys.nl>, Thomas Beauchamp <robotomas2001@yahoo.co.uk>, freebsd-security@FreeBSD.ORG Subject: Re: recovery from 'rm -rf /' Message-ID: <Pine.BSF.4.21.0110282153500.15815-100000@athena.za.net> In-Reply-To: <20011029065239.F75481@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0110282153500.15815-100000>