Recently I read some information about computer security focusing on securely wiping files, disk free space, swap space, and RAM.

For those unaware, apparently the contents of RAM does not dissipate as quickly as most people would think after hitting the power button. This was more or less in the headline news some time back.

Some of the writers mentioned all or some of a suite of tools named secure-delete. There are four command line tools in the suite: 1) srm, 2) sfill, 3) sswap, and 4) smem.

I wondered how these tasks would get accomplished in the stock Slackware.

I searched for a slackbuild script for the suite of tools and found none at the popular repositories.

The srm command is available at slackbuilds.org, but for most people I think shred will fit the bill for secure deletions of files. Shred is part of the stock Slackware.

The sfill command is for wiping free space on a disk partition. On a stock Slackware I can perform the same task with two commands:

dd if=/dev/zero of=/bigfile
rm -f /bifgile

The sswap command is for wiping swap space. I can perform the same task on the stock Slackware like this:

swapoff -a
dd if=/dev/zero of=/dev/sda2
mkswap /dev/sda2
swapon -a

I don't pretend that these three methods are as robust at the secure-delete tools, or satisfy any security standard or protocol, but for me are more than acceptable options.

So far so good for the stock Slackware. No additional tools or packages required.

I haven't yet figured out on the stock Slackware how to wipe RAM during a shutdown. I admit such a task is for the truly paranoid, but that does not remove the technical challenge or fun of discussion.

Any ideas how to securely wipe RAM during a shutdown?

The parlor is open.

I notice that creating a large file like you said seems to use up all the RAM disk cache. I suspect this also wipes the RAM. I'm not sure how to test this tho. I suppose memtest will wipe RAM for sure, because it uses test patterns to test all of it.

wouldn't /dev/random or /dev/urandom do a better job than /dev/zero?

Might want to read up on the "facts" first

http://citp.princeton.edu.nyud.net/pub/coldboot.pdf

Of particular note is the requirement for cooling of the dram chips to enable data retention for more than a few seconds.

1 members found this post helpful.

Perhaps in the days of low density MFM/RLL disks things were different and overwriting multiple times with random data (or even specific patterns) was necessary, but with modern drive hardware storage density is so high and tolerances are so low that I very much doubt anyone needs to worry about any residual magnetic image left on the platter.. And with RAM it's even less of an issue.

/dev/urandom and especially /dev/random are painfully slow, and though it's worthwhile to use them to prepare a partition for something like luks encryption, there's really no need to use them for a simple wipe. A single pass from /dev/zero should suffice - unless you feel the need for an exceptionally large tin-foil hat.

Back a few years I was administrator of secure systems (meaning really secure as in classified secure). One requirement that came along was a secure disk file delete which required, as I recall, overwriting a file with zeroes, then with ones, then with zeroes again, then unlinking it. I did that with a random number generator that essentially did coin flips (seeded from the clock, carefully evaluated to make sure it actually did that, all that stuff) and rm got replaced with a utility that did just that: point at the beginning of the file, generate random numbers, write the entire file three times, byte-by-byte, then unlink. The Powers That Were liked that approach. I wound up using the same approach for clearing RAM (little trickier but doable) on system shutdown and in terminals that contained RAM; find the beginning, find the end, point at the beginning and walk it. These were UNIX System 3 boxes.

As an aside, when you have a secure system you cannot let the disk drives out of the computer room (which, of course, is padlocked and alarmed and all that) -- so, if a system is sold or scrapped, the drives stay in a safe until you can ship them to an approved facility that can, literally, grind them in itty-bitty pieces.

Another thing is that most people don't realize that many copy machines (the big ones that you can also use a printers) have disk drives in them and that those drives contain pretty much everything you've copied for the last X amount of time that it took to fill the disk drive. So, if you care about your information getting out, pull the drive(s) out of the thing before you let it out of the building (ever wonder how the Chinese get all those plans for facilities? scraped computers and copiers, folks).

Anyway, just a couple of thoughts.

1 members found this post helpful.

When it comes to spinny disks, GazL is probably right when he says that zeroing is about as much as you can do. I am afraid, though, that recovery methods where a disk is read with a very high resolution head will still sometimes work. (Your drive's head is wide and does not position itself very precisely, so when it writes, there's often a "gutter" left over where your old data can be cleanly read.) Because of that, I personally wipe disk files with shred -z (which comes with Slackware), and pray that 4 passes are enough.

I don't think even that is good enough for really sensitive files. These never touch a magnetic surface, but get decrypted into a ramfs mount. My data is very low-profile, so I don't wipe my RAM. Recovering from cold RAM is a very tricky and very expensive forensic procedure, and I just don't see it happening to me. Really, they would have to get an order and send a couple of black vans to my house/office. Agents would have to kick down a few doors, power down my systems, and recover my RAM within a few minutes. Even then, success is far from guaranteed.

I wouldn't put much faith in overwriting files with things like shred these days. Almost all the modern filesystems write a new block and then change the pointers rather than overwriting the existing block in place on disk.

From shred's manual page:
Ensure that nothing hits the platter unencrypted, and if it really matters... take-off and nuke it from orbit (it's the only way to be sure!)

1 members found this post helpful.

Only too true, GazL. I do believe, though, that with the default mount option data=ordered, ext3 and ext4 do perform honest overwrites (the same man page). But like you say, it's too much risk anyway, if only because things may get cached and then swapped, and no one really knows what exactly the hardware does these days. SSD in particular are infamous for refusing to owerwrite.

When you stop and think about it, why would a controlling entity require you to do multiple passes on erase or clear RAM?

Same reason you can't have a display pointing toward a window, same reason you should have metal grids embedded in the walls to block high frequency radiation (like, from a terminal or display -- anything that radiates can be monitored), same reason that fiber optic is more acceptable that unshielded cable (or even shielded cable) -- really, really hard to tap fiber optic, child's play to tap wire: The boys and girls down to the spy shop can do it and they figure that if they can so can the other guys.

And, oh, golly gee -- absolutely no wi-fi (and shut off or better yet remove the transceiver in any devices so equipped). And lest we forget, filter the power lines while you're at it. And absolutely never allow any media in or out of the building (floppies, CD-ROMs, and particularly memory sticks -- also no electronic cameras [the memory card!]); disable or remove USB ports, people can be sneaky.

It's possible to go a little overboard with this stuff but, if your stuff matters to you or some other interested party, it doesn't hurt to treat it like it's code-word classified. Encrypt the heck of everything, don't ever let a disk drive out of the building (literally chop the platters into little tiny pieces), remove drives from copiers and printers, use fiber optic hung in plain sight (and inspect it regularly). All that kind of stuff -- a little paranoia goes a long way if your stuff really, really matters.

And, last but not least, never, ever connect the machine(s) to the internet. Under no circumstances. Use a separate box for the internet, carefully examine anything you plan to copy onto you secure system(s) (using optical media subsequently chopped into tiny pieces). Keep your back up magnetic or optical media in a safe (not a desk drawer) and totally destroy it when you're done with it (just smashing a drive doesn't do it, you gotta chop up the platters).

Whew.

Just for the sake of the post I actually compile the tool in question. Works ok so far.

Thanks for all the responses!

As I mentioned in my original post, being able to wipe RAM is for the truly paranoid. I don't have any ideas about wiping RAM. Does anybody have an idea how to wipe RAM at shutdown?

Not that I need do any of these tasks. I am simply curious how to perform such tasks on Slackware. I thought soliciting solutions would make for an interesting discussion.

In the real world, I can't envision any standard raid by intruders to be fully prepared to freeze RAM in order to view the contents. I suspect that even if a person had warning of 30 seconds or more to be able to actually invoke a shutdown of the computer, that by the time intruders seized and froze the computer the contents of RAM are long gone.

For most users wiping hard drive free space and swap space is only a nominal security tactic that does nothing about the actual data content remaining on the disk. Yet the exercise is fun for the technical challenge.

Many of us have seen movies or TV shows where people realize they are about to be raided and they begin a destructive shutdown of all computer systems. How to perform such a shutdown might be an interesting discussion too. Short of physical destruction, any wiping of hard drives would have to be very quick. To perform a quick wipe I imagine such systems would not contain lots of data. The more data the longer the wipes. To preserve hard drive data, any sufficiently trained intrusion invader would simply pull the plug on all computers and not worry about safe shutdowns.

The bottom line about security is perceived risk vs. perceived benefits. I'm not going to wear a tin foil hat and develop a self-destruct strategy because I do not (yet!? ) have any such need. I can imagine some people in this world needing such a strategy, but I'm not one of them.

Originally I had considered memtest as a tool for such a purpose. But memtest runs independently of an operating system. My goal for the sake of discussion was how to wipe RAM at shutdown. Again, for the truly paranoid or needy, but an exercise in fun discussion.

As GazL mentioned, I had read that /dev/urandom is too slow. My thought for this discussion was to perform the basics and /dev/zero seems fast enough for that.

I agree. I can't imagine a significant number of raids where intruders are able to freeze the contents of RAM or are even prepared as such. If a person is a well known world-class hacker then perhaps intruders might be prepared for such an act. Yet a world-class hacker is going to be prepared for any such raid.

Sounds very much like the srm tool. Perhaps the same could be accomplished in the stock Slackware like this:

cat /dev/zero > /name/of/file
cat /dev/urandom > /name/of/file
cat /dev/zero > /name/of/file
rm -f /name/of/file

Ah. So shred probably is insufficient. Perhaps building the srm tool is better for those who need such a tool. Then again, for occasional secure cleaning of a hard drive, using normal file deletion tools but then regularly wiping all free disk space would do the same trick. A daily cron job could keep free disk space clean. Again, risk vs. benefit. The higher the perceived risk, the more a person should investigate more secure strategies.

Did you create a build script?

To tell you the truth there is no need too...

The application was very simple to install.

Hm. Ok. I prefer packages to control installation and removal of software. I can create a build script if that is all that is needed.

You are kind of answering your own question, Woodsman, when you talk about memtest and Slackware. A proper RAM cleaner cannot be a part of an OS, as it would have to take over the execution and nuke everything but its own code. Here is my guess why there is no standard tool for this task: it would be about as effective as an emergency shutdown, but it comes with a really nasty overhead. To wipe DRAM, for example, you want to keep rewriting it the whole time your OS is running! When you realize that you are about to be cold-booted, you have a window of action only a few minutes long. During that time, you may choose to cut the power for instant shutdown, or start scrubbing. With 8 or 16 GiB of RAM, you may not even be able to finish in time.