Brochettes de Sécurité

Ah, François. Come here and take a look at this. The theme of this issue is security, and I have developed a menu around that very theme. Quoi? But of course it is not about networks. Do you know, mon ami, what the most important part of running a successful restaurant is? Bien sûr, a well-stocked wine cellar is important—I agree with you, but I was thinking about the food, François. You see, our guests, they hunger for many things, and it is our duty as restaurateurs to make sure that their taste buds are constantly stimulated in ways they do not expect.

Qu'est-ce que tu dis? François, security is a many-faceted aspect of cooking with Linux. Network security is but one such item, and everyone no doubt will be thinking network security. By selecting different ingredients, we keep the palate alert and refreshed. For instance, look at this first item. You cannot deny its security implications and yet—François, why are you not paying attention? Eh? Ah, mais pardon, I see our guests have arrived. Please, everyone, sit down. I shall have François fetch some wine immédiatement.

François! We have a 1998 Clos de Vougeot in the cellar that I think will satisfy everyone's taste buds tonight and add a special air of je ne sais quoi. A lovely Burgundy, mes amis. Vite, François. Vite!

François and I were discussing different ways to look at the concept of security. When we cook with Linux, we have all gotten used to thinking of “security” as network security but, as a visit to Monsieur Roget and his famous thesaurus will tell you, security can mean many other things. You will find words like bond, debenture, deposit, bail, hostage, plight, authentication and receipt, just to name a few. And what about the security you enjoy in knowing that you make regular backups? You do make regular backups, non? Then, we have job security, the kind of security you experience knowing you make regular backups. A little joke, non?

In all seriousness, losing a file can still happen, and what if your last backup was last night or even two hours ago? Despite good habits and a healthy attraction to job security, you still have lost your file. What can you do? Common wisdom, as they say, informs us that if we delete a file from our Linux systems, that is all, mes amis. It is gone forever. However, that is only partially true. It is possible to bring back a file. Observe.

On my test system, I have a small drive mounted on /mnt/tinydrive. If I use the command

df /mnt/tinydrive

I get the following information:

/dev/hdd6   42913   9063    31634  22% /mnt/tinydrive

I told you that it was small, non? On this small drive, I created some directories and files. One file is called cabernet, and it contains my family's Cabernet secrets. Actually, it does not contain any such thing, but it sounds so mysterious. Speaking of Cabernets, François has returned with the Burgundy.

Now, if I list this file, it shows up like this:

$ ls -l
-rw-r--r--  1 marcel  wines  77 Jun 21 04:38 cabernet

At 77 bytes, you know the secret is elegant. Now, if I remove this file with rm cabernet, it is gone for good, and it cannot be read. And yet, with a little perseverance and luck, you can bring the file back as I will show you. It is important to unmount the drive in question immediately (or shut down if the file is on your root drive):

umount /mnt/tinydrive

The more time that elapses (and consequently, the more data that gets written to the disk) from the time you delete a file, the slimmer your chances of recovering it completely.

In order to attempt a rescue of the data in question, I use a program called debugfs. Have no fear, mes amis. You will find this command on your system. It is part of the e2fsprogs package:

# debugfs /dev/hdd6
debugfs 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09
debugfs:

If I type lsdel at the debugfs prompt, I will get a listing that looks something like this:

7665    0 100644  5248   6/  6 Thu Apr 19 18:05:30 2001
  32  500 100600 12288  12/ 12 Thu Jun 21 04:38:39 2001
 158  500 100644    78   1/  1 Thu Jun 21 04:38:39 2001
 157  500 100644    77   1/  1 Thu Jun 21 04:40:25 2001

The first column is the file's inode. The second column is the UID of the owner. Since my UID was 500, and my accidental deletion occurred on Thursday the 21st, it is starting to look like my file might be one of those listed. Furthermore, I recall that my file was 77 bytes long. There are no filenames listed so as you can imagine, the more details you know about the original file, the better. Still at the debugfs: prompt, I enter the following:

debugfs: dump <157> /home/marcel/cabs

The 157 is the inode number, and /home/marcel/cabs is a file on another (still) mounted filesystem. By using the dump command to debugfs, I can redirect the contents of inode 157 to a new file called cabs. Now, let us look at the results of this operation:

$ cat /home/marcel/cabs
Why try making fine Cabernets when you can buy them
from Henri's Fine Wines?

Mais non! The secret is out!

Another tool you might find useful to restore those lost files is a little program called recover. Written by Tom Pycke, recover makes the whole process of trying to work your way through what can be an incredibly long list of deleted inodes quite a bit easier, one might say virtually painless. To get a copy of recover, head on over to recover.sourceforge.net/linux/recover. Download the latest source, then extract and build it. It is all very easy:

tar -xzvf recover-1.3.tar.gz
cd recover-1.3
make
make install

To use the program, you can simply type recover, and it will scan for the various filesystems available on your system. You can also have it start with the appropriate filesystem by specifying it on the command line. What follows is a question-and-answer session designed to narrow down your deleted file without having to go through a huge listing. The recover program massages the data for you. Here is an example:

# recover /dev/hdd6
Recover v1.3 by Tom Pycke <Tom.Pycke@advalvas.be>
Getting inodes (this can take some time)...
debugfs 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09
In what year did you delete the file? (eg. 1999): 2001

The program then asks for the month followed by a date and time range as well as a range of possible file sizes. When everything had been answered, I received the following output:

=> 158 78 JUN THU 21 4:38:39 2001
=> 157 77 JUN THU 21 4:40:25 2001
2 inodes found. Where shall i dump them?
(directory):  /tmp

The files will get named dump157 and dump158. All that is left is to view their contents with cat. On the off chance that these may be binary files, it might make sense to use the file command first.

Security has another side as we well know (and as Monsieur Roget figured out as well). We may be secure in the knowledge that we can recover a deleted file from our ext2fs filesystem, but what of the other side? What if the information in the file was of a top-secret nature, and I did not want to risk having anyone ever see this file again? What if I would rather have this file disappear into some dark region completely inhospitable to proper viticulture? There could be implications of international security should this information get out.

If your system contains a recent version of the fileutils package (which contains programs like cp, mv, etc.), the solution is at hand. You will find a program called shred that will take your file and, ahem, shred it:

$ shred secret_instructions

If I use the command as above, the file secret_instructions will be secret indeed, but it will not be deleted. It will, however, be scrambled, much like a well-whisked omelette. For the truly security-conscious, it may be better to use this version of the command:

$ shred -z -u secret_instructions

In addition to scrambling, the program will overwrite the file with null characters (the -z flag), then remove it completely (-u). Your secrets are safe, mes amis.

We started today's culinary exploration with a slight hint of backups. Let us say then, that you archive your data to tapes regularly (a very good idea—I must commend you, mes amis). Those tapes are then moved safely to off-site storage. You may well have backed up those secret files that you so desperately wish to remove from your system. Let us pretend that I have archived the /etc/profile file using tar:

tar -cvf /tmp/profile.tar /etc/profile

That simple tar file is quite transparent:

$ more /tmp/profile.tar
etc/profile01006440000000000000000000001163072353 262310117170
ustar  rootroot
# /etc/profile

As you can see, the contents of the file or files that exist are visible on the archive. But of course, mes amis, I know that I could simply extract the files with a little

tar -xvf filename.tar

but I wish to illustrate a point. What if all our tar archives were encrypted? This is the idea behind sectar, a secure extension to GNU tar written by Brian Wagener and Katrina Illari. You can pick up the latest sectar from sourceforge.net/projects/star.

You will need two packages. One is a patched version of the GNU tar release. The second is sectar. Start by extracting the tar package and building it:

tar -xzvf tar_sectar.tar.gz
cd tar-1.13
make
make install

This is almost identical to the original tar package you have on your system, except for a very interesting option. If you type

/usr/local/bin/tar --help

you will notice the following:

-e, --encrypt   filter the archive through encryptor

Ah, the mystery...but to use this feature, you must first build the sectar package. Using the latest source, I followed these steps:

tar -xzvf sectar-1.02.tar.gz
cd sectar-1.02
make
make install

Using this newfound power of encryption, I will re-create my top-secret archive:

$ tar -ecvf /tmp/profile.tar /etc/profile
The 256 bit key created is keyfile.993515072

I can now take this keyfile (which is located in my working directory) and save it to a diskette or secure location for the day when I need to restore my file. If the keyfile is in place, then extracting data from the tar file is a breeze. However, in the absence of the keyfile, your information remains secret. When we look through this archive again (sans keyfile of course), what we see is garbled, unreadable and certainment unprintable.

Once again, mes amis, the time, she is late and we must all start thinking about going to our respective homes. You too, François. But before you do, please refill our guests' glasses. All this intrigue has no doubt done little to slake their thirsts. Unlike Monsieur Bond, pour the wine gently, neither stirred nor shaken. Wonderful. Merci, François.

Mes amis, it has been a pleasure once again to serve you here at Chez Marcel. Do remember to join us again next time. François will have your table waiting.

A votre santé! Bon appétit!

Resources