This article is more than 1 year old
Data security for Linux power users
Frustrating three-letter agencies
Howto A couple of months ago I wrote a security howto for Linux newbies, the goal of which was to help people achieve decent security using easy and safe techniques. Now it's time to address you power users out there, by which I mean people comfortable with the command line, using a text editor from the console, and tweaking configuration files -- people confident enough in their ability to recover from unpleasant surprises to take a bit of risk with their systems in the interest of securing their data and their privacy.
I'll get into the Linux home network soon in a forthcoming article with our John Lettice. For now I'll concentrate on data hygiene and on-line anonymity. Why? because your Linux box is literally peppered with data traces indicating the Web sites you've visited, the files you've uploaded and downloaded, and every file you've recently accessed. You think encryption is the way to go? Think again. It's only as private as your passphrase is strong. It may be impractical for a remote attacker to crack it, but a brute-force attack is quite plausible for someone who has physical possession of your box and plenty of time. Like a police forensics lab, say.
We used to worry chiefly about people in neurotic countries like China and Saudi Arabia, where the mere possession of forbidden information or politically inconvenient materials can result in criminal action. But now, in the wake of the 9/11 atrocity, we in the enlightened West have narrowed the gap. In Europe there is a movement underway to mandate data retention for all carriers. In the USA electronic surveillance orders which used to require a judge's approval are now available for the asking. Black bag jobs are going mainstream. Librarians have been conscripted into rat duty for the Ashcroft/Ridge Black and Tans, and risk prosecution if they so much as whisper about the loathsome things they're now forced to do in the name of Homeland Security. A recent report by the FISA (Foreign Intelligence Surveillance Act) court of appeals found that the FBI had lied like children about their evidence on over seventy recent occasions to get surveillance warrants they weren't entitled to, and that all happened before 9/11. Western governments are exploiting 9/11, making every move towards authoritarianism that they can get away with, and will only continue to test the waters and grant themselves ever more authority to regulate our lives and supervise our private affairs. The convenient myth of cyber-terrorism is never far removed from the rhetoric of bureaucrats and politicians. The momentum is all wrong, and building steadily.
So for these reasons we need strict data privacy and on-line anonymity. Unfortunately, the Internet and the personal computer are designed for the storing and exchanging of data, not for its security. You think your Linux box is somehow more secure than a Windows machine? Think again. The beauty of Linux is its modularity; but this is also its curse. There are so many possible configurations that securing it is considerably more challenging than securing Windows (though the ultimate result will be better if you know what you're doing). Therefore we'll be dealing with only one filesystem, only one browser, only one desktop. To attempt more would require me to write a book, not an article.
Forget journaling
Everyone is talking about the journaling file systems for Linux: ext3, ReiserFS, XFS and JFS, etc. If uptime is job one for you, these are the way to go (my personal faves from a performance POV are Reiser and JFS, incidentally). But if security and data hygiene are your priorities, then there is only one way to go: ext2.
The journal is a little treasure chest of data about your data. Get rid of it. Now, Reiser, XFS and JFS are designed for performance, and they really do deliver -- JFS in particular IMHO. But consider that they need memory and that this is a significant performance issue for Linux. Some of what you'll lose in data access speed will come back to you in the form of freed RAM, so it's not quite as sad a choice as some would have you believe. Furthermore it is rock solid. But yes, ext2 is generally slower and takes forever to recover from a crash. But if security is your first priority this is a no-brainer.
I'll be providing a few homebrew tools for secure data wiping below, but I really can't recommend them on any other filesystem. Unless you're using ext2 you won't be able to exploit them fully.
KDE
I use KDE, as I hope all you happy Tuxers out there do. If you don't, then I'm not going to be able to help you as much as I'd like; but read on anyway -- there's a lot you can use below.
KDE stores an absurd amount of data. Did you think that by disabling the recently-accessed files menu on your desktop via the KDE Control Center you'd no longer have a record of them stored on your machine? I hate to break it to you but KDE dutifully records all of it in a directory called /home/youraccountname/.kde/apps/share/RecentDocuments. Just wipe everything in that directory and change its permissions to read-only. Problem solved.
Oh, but there is so much more. Go to /home/youraccountname/.kde/share/apps/ and start nosing around. The sub-directories I'd be most concerned with here are /RecentDocuments, /kbear, /kcookiejar, /konqueror, /krusader, and /noatun. In /konqueror you'll find several files, some of which need to be opened and given the 'select all/delete/save' treatment and their permissions set to read-only, in particular faviconrc and konq_history.
I assume you're not foolish enough to bookmark 'dangerous' sites, so leave bookmarks.xml alone for convenience. You can always use Google as a way of avoiding bookmarking and of avoiding typing in the browser's address bar when you're surfing on the wild side. [Reader Rickard Ekeroth spotted konqueror's typed URLs history in ~/.kde/share/config/konq_history, which can be emptied and made read-only.] But I can't recommend konqueror as a secure browser because several settings are not as easily managed as with Mozilla, which we'll be dealing with in detail presently.
I haven't used kbear but I suspect that the directory will contain all the details of your uploading and downloading history, so get into that subdirectory and start reading, and if this info is stored give each file the 'select all/delete/save' treatment and set the permissions to read-only. Do the same for any suspicious file in any of the sub-directories mentioned above. /noatun has a file called splitplaylist.xml which can get you into incredible hot water if you've ever opened a KP flick accidentally during your neverending pr0n quest.
Now go into /home/youraccountname/.kde/share/cache and do exactly the same as I described above: delete text and change permissions with a vengeance. If you're one of those devil-may-care studs who works exclusively from the root account, then just do all this in /root/.kde/etc...
'Zilla
I have a longstanding love/hate relationship with Mozilla. I use it exclusively and accept it willingly, warts and all. It is buggy. It is also quite easy to configure for maximum data privacy and on-line anonymity. But of course you do have to configure it. Let's assume you've installed the latest stable build (and if you haven't, you should). Here are my tips for making it tolerably secure:
Go to Edit/Preferences in the drop-down menus and do a thorough walk-through along these lines. Start with Navigator/History. Select zero for "Remember visited pages for the last X days." Clear the location bar history, and come back and do that often. Now go to Helper Applications and disable everything. Next go to Smart Browsing and disable everything. Go to Downloads and tick "Don't open anything."
Next go to Mail & Newsgroups and disable everything. Kmail is the only client I recommend for the home user. It imports gnupg easily and defaults to a plain-text display which thwarts worms and malicious scripts. Stick with it unless you really know what you're doing.
Now head into Privacy & Security and start with Cookies. Choose "Enable cookies for the originating site only" which thwarts third-party advertisers, and set "Limit maximum lifetime" to "Current session only." Don't worry about cookie-borne passwords, which will be lost whenever you close the browser. You can save some of them (not crucial ones like those for your bank accounts) with the Password Manager. You definitely don't want cookies piling up on your machine. They can reveal your entire browsing history. While you're mucking about here go to "Manage stored cookies" and delete all of them. Do this regularly.
Now go to Images and restrict them to those originating from the Web site you're visiting. Magically, a score of irritating advertisements will disappear from your surfing experience. This is also excellent for those times when you want to use the Google cache as a proxy. You won't be fetching images from the ultimate target site and you will therefore not show up in their server logs.
When accessing controversial sites it's always a good idea to search via Google and to view only cached pages. This prevents the site name from appearing in your bookmarks, URL history and favicons list; and the Images trick above prevents you from making direct contact. Restricting your cookies to the originating Web site means that only Google will plant one; and setting them to expire with each browser session will prevent the notorious Google cookie from swelling and storing your comings and goings over time.
Now go to Pop-ups and reject. Go to Forms and do the same: forget about storing this data; it's evil.
You can go to Passwords and store those that aren't important. For example, my login information for the New York Times is stored. Of course my NYT profile identifies me as a 76-year-old Ethiopian grandmother of eight with a keen interest in fine wines and fast cars ;-)
Now go to Advanced and disable Java. Go to Advanced/Scripts & Plugins and disable everything there. If you need to use these viral items you can enable them temporarily but you should run without them as much as you can.
Now go to Cache. Enable the memory cache and give it as much as you can reasonably spare. Set the disk cache size to zero. While you're about it, click on the button to clear the disk cache. (Later we'll verify that it's empty and make it a read-only file.) The cache is important; it can store immense volumes of your surfing history including images, some of which may be verboten. It is possible in the USA and other neurotic nations to bust any poor bugger for KP possession merely on the basis of images stored in the browser cache. That you may have been deceived into following a link to some sicko Web site will do you no good in court. Child-protective hysteria reigns and you need to protect yourself from it.
Finally, go to Networking/Debug and disable the disk cache and enable the memory cache. I don't know what effect this has but it seems prudent.
With this setup you're going to have problems with aggressively viral Web sites like MSN and Hotmail which demand all sorts of access to your machine in exchange for the privilege of visiting them. You will have to adjust your cookie, Java and JavaScript permissions for each visit and then restore them when you're finished. You can create a separate profile for occasional unsafe browsing if you wish. Or you can just stay away from these sites, which is what I do. If I can't access a Web site with tight browser settings, then I figure the site in question doesn't need my business. If enough people did this they'd soon ease up on their Java, JS and ActiveX requirements.
Now, Mozilla will have graciously recorded your entire http and ftp download history, so we'll need to deal with that. Go to /home/youraccountname/.mozilla/yourprofilename/whatever the next directory is and find downloads.rdf. Give it the old select all/delete/save treatment and make it read-only. Have a look at what's inside history.dat and history.mab. If you don't like what you see, do the same with them. Now go to the subdirectory /Cache and wipe everything inside it. Make this directory read-only too. Snoop around in the /.mozilla directory tree and wipe and/or make read-only any file or directory that makes you even vaguely uneasy. Don't just delete directories. Many of them may be re-created by the application (this is true for KDE too). It's better to empty them and make them read-only. Some files may also have to be present for the app to run properly. Here again, deleting the contents and making it read-only is the better way to go.
For information on using proxies for additional on-line anonymity, and numerous other tips, see our previous Linux security article.
One last tip: your bash history is a significant convenience that I would hate to see you do without. But pay attention to your commands. Ones like shred -z /home/me/docs/atomic_bombmaking.pdf or DaddyRapesSister.avi are not particularly healthy to keep in history. When it comes to file wipes the GUI is actually safer, and I would recommend using Krusader so there's no history of which files you've shredded.
Wiping
Now we have a few problems. For maximum security I advise using a non-journaling fs, and I also advise strapping on extra RAM in lieu of using a swap partition. Of course we can wipe the swap partition occasionally; and we can wipe the unused space on our active partitions. Unfortunately there's nothing I know of that will securely wipe the file slack-space on an active Linux fs (readers feel free to come to the rescue here); but I have dashed off three shell scripts which will securely wipe, according to your needs, an entire disk and its contents, only the unused space on an active disk, or a swap partition. I would like to have integrated the script which wipes free space with the one which wipes the swap partition, but the former can be run safely in the background while the disk is in use, while wiping the swap partition may cause applications to crash. It needs to be run separately from the console with nothing else going on. Obviously, wiping an entire disk is something you do from a boot floppy or from a separate HDD in preparation for a new tabula rasa sort of installation.
These routines take an incredible amount of time, up to 48 hours for an entire disk of say, 40GB. With the WipeFree script we're overwriting the unused disk space in /root, /var, /home and /tmp with random data, and then overwriting that with zeroes to conceal the fact that we wiped it in the first place. With the WipeAll script we're devastating an entire HDD in basically the same way, but overwriting all data. With the WipeSwap script we're eliminating the contents of an entire swap partition, but I do recommend setting up a Linux box with no swap partition if you can afford enough RAM. I am not aware of any Linux app that absolutely requires disk swapping, though with Windows several will fail to load without disk swapping no matter how much RAM you have (e.g., Photoshop).
Each of the scripts would be quite easy to run from the command line. There's no magic here. I'm not a programmer and I don't play one on TV. I've scripted them simply for convenience. For example, you might wish to run WipeFree.sh before going to bed and expect to rise after it's finished. If you did the same from the command line you'd have to wake every three hours or so to switch directories.
There are caveats for WipeFree.sh. There is no wiping of file slack space. Using it on a journaling fs is not secure since the journal maintains data about your data. Even using it on an non-journaling fs is only effective if you're truly paranoid and proactive. Your own bad habits can easily defeat it. And then there's the slack space problem.
'Trust nothing, fear nothing' is the best security mantra I can offer.
In any event you can download the utilities here. If anyone (like a real programmer, say) wishes to assist me in improving them, by all means please contact me. ®
Note: thanks to reader Conrad Wood for speedily adding swap device auto-detection to wipeswap.sh. --tcg