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
I get the following information:
/dev/hdd6 42913 9063 31634 22% /mnt/tinydriveI 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/tinydriveThe 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 2001The 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/cabsThe 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): 2001The 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): /tmpThe 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_instructionsIn 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/profileAs 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.tarbut 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 --helpyou will notice the following:
-e, --encrypt filter the archive through encryptorAh, 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 installUsing 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.993515072I 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!
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide