Date: Mon, 24 Feb 2020 18:22:29 +0100 From: Polytropon <freebsd@edvax.de> To: "Kevin P. Neal" <kpn@neutralgood.org> Cc: Jos Chrispijn <bsduser@cloudzeeland.nl>, freebsd-questions@freebsd.org Subject: Re: rm | Cleaning up recycle bin Message-ID: <20200224182229.1b670c54.freebsd@edvax.de> In-Reply-To: <20200224145317.GA9130@neutralgood.org> References: <a589bf69-a53b-a732-08ff-74e09b723bbd@cloudzeeland.nl> <20200223184908.b35d656a.freebsd@edvax.de> <20200224145317.GA9130@neutralgood.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Feb 2020 09:53:17 -0500, Kevin P. Neal wrote: > On Sun, Feb 23, 2020 at 06:49:08PM +0100, Polytropon wrote: > > On Sun, 23 Feb 2020 14:05:35 +0100, Jos Chrispijn wrote: > > > I read somewhere that using the rm command does not phsyically remove > > > the 'deleted' files when using the command in a terminal session. Can > > > you tell me how/where I can really remove these files (as per user > > > account or in general)? Thanks! > > > If you also want to remove the _data_ (read: the former file > > content), you need to overwrite the file's content with a > > random pattern or with zeros first. This can be done with > > the dd tool. There is also a port called "secure rm" (srm) > > that achieves the same "by overwriting, renaming, and > > truncating it before unlinking". You can find its manpage > > with further suggestions here: > > > > https://www.freebsd.org/cgi/man.cgi?query=srm > > > > However, this does not change things related to disk space > > becoming free. So when intending to simply remove files > > without any "recycle bin" nonsense, rm is the way to go. > > The thing about security is that often all you can do is raise the cost > of an attack. If the cost is high enough then you can often make an attacker > find a better use of their time. Fully agree. In 99% of the cases, it's not about "possible or impossible", but about "how much effort can you afford", as even data overwritten with random garbage and zeros _can_, given specific circumstances, be recovered. > Using forensics tools on a disk to recover a file that has been deleted > is pretty low cost. Still, I wouldn't expect the average street criminal > to be able to recover the files. The guy that broke into my house and > stole a jar of coins couldn't do it, for example. Using the _appropriate_ forensic tool requires a bit of experience, usually preceeded by reading, learning, and thinking, but yes, it is absolutely possible. I know this, because due to fat fingers I had to do recovery for accidentally deleted files more than once. ;-) > For example, SSD's will do wear leveling, and that means that a write to > a block at a particular offset will typically end up going to a different > physical block on the drive. The previous contents won't be available > to normal use, but tools no doubt exist that can recover the previous > block. A good example. Especially with SSDs, you cannot exactly predict _where_ a write operation will take place - will it be the same memory cells that previously contained the file, or will the controller choose different memory blocks and dynamically map them to the "original" blocks, as in "you told me to overwrite block 12345, I report back that I've overwritten block 12345, but I don't tell you that I actually chose block 987654 to be addressed block 12345". :-) > So, what's the threat you are trying to protect yourself from? _This_ question is the beginning of the search for the right(TM) tools. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200224182229.1b670c54.freebsd>