Archive | February 2008

Top 10 Linux FUD Patterns, Part 5

Linux FUD Pattern #5: Linux is not secure

There are some out there who would like for you to believe that Linux is unsafe. What better way to instill fear than to form doubt in your mind about a system’s abilities to protect your data?

A reason for the supposed lack of security often cited in FUD is the origin and maintenance of Linux in the “hacker” community. The term “hacker” has evolved from a term of endearment to one associated almost exclusively with cybercrime. To say that Linux was created and is supported by hackers gives the impression that the OS and its related applications are riddled with built-in security holes, backdoors for gaining system access, spyware for purposes of identity theft, hidden network tools that help intruders cover their footprints as they travel from machine to machine through cyberspace, and any other sort of malicious software for various and sundry purposes. To “hack” no longer means to “tinker” or to “fiddle with”, but to “break into” and “cause harm”. The term may conjure mental images of a scene from a horror movie, an evil man with an axe about to hack his way through the door to the house protected by the dark of night. Such is the imagery used to spawn fear.

Let’s examine Linux security by answering two questions. Do security components exist? And, can they be trusted?

The components required to make a system secure depends on many factors, because different systems are used in different ways by different people. Moreover, a weakness in a system’s security may be mitigated by strengths in some other compensating controls. There are some basic options that are commonly used to secure systems, all of which are available on Linux.

Password protected login is the hallmark form of authentication. It is easy to implement, easy to use, can be highly effective, doesn’t require additional/expensive hardware and the expectations and conventions surrounding it are already present in modern culture. Sure, there are more advanced biometric devices such as palm readers and retina scanners, but the relative cost in money and effort of implementing these safeguards for the average home user and for most business desktops is prohibitively high. There are two aspects to password security: the strength of the password itself, and the authentication scheme behind it. Password strength is the responsibility of the user, not the OS. Most Linux distros either require password protection or at least have it enabled by default. Usually, the passwords are protected on the local system by shadowing and various schemes such as Kerberos can be used to protect the transmission of login information over a network.

Related to password authentication is the file system permissions granted to users once they’ve logged in. Linux and Unix use file-based permissions, denoting how the owner, members of the owner’s primary work group and the “world” of users on the system can interact with each file or directory. Privileges do not cascade as they do with other operating systems that use Access Control Lists.

Network security is a broad topic encompassing the combined abilities of the OS, applications, network devices, administrators and users to detect and/or prevent a breach attempted across a network connection. A basic way to accomplish this is to disallow certain types of messages from reaching the computer; this function is usually performed by a firewall server or program that monitors network traffic and filters communications based on predefined rules. Every computer that communicates over the Internet uses the TCP protocol, which allows for approximately 65,000 possible “ports”. These ports are similar to radio stations or TV channels; each application that needs to communicate does so using one port. Ports that are not used by an application but are still available for use (“open”) can be exploited. Port scans are a good way to determine if a system has any open ports that are not being used. Firewall capabilities are built into the Linux Kernel and several good front-end packages are available for configuration, monitoring and reporting purposes.

All of the safeguards discussed above constitute protection around the data. What about protection of the data? A data file can be encrypted thereby changing the contents to an encoded, unreadable format. The content is usually restored using a key or a password. E-mail can also be encrypted prior to transmission. GNU Privacy Guard (GPG) is a Pretty Good Privacy (PGP) compliant application that implements public key cryptography on multiple OS platforms, including Linux. Of course, constantly having to decrypt and encrypt every individual data file before and after use would be painful; instead, entire file systems can be encrypted by the system and several cryptographic file systems exist for Linux. It is also possible to create a loopback device, which is a file that can be mounted as an encrypted file system similar to the commercial product Cryptainer LE by Cypherix.

So, the components do exist. Now, the question remains, can these components be trusted?

FUDsters will argue that any security software for which the source code is freely available to the public is inherently not secure. This is based on the assumption that the source code will either reveal the secret functionality that makes the security software work or expose bugs in the security software itself that can be exploited as well.

First, if someone cannot open their source because they are afraid it may reveal secret functionality, then it wasn’t properly designed from the start. The worst-possible example of this is hardcoding passwords in programs, especially if they are scripts stored in clear text. Good security schemes, such as encryption, rely directly on information the user provides, and often make use of one-way functions.

Second, Open Source software is available for public scrutiny. If you cannot read and understand the code yourself, rest assured that there are many folks out there that can and do. Why? Because many businesses do actually use Open Source software and have everything to lose if they don’t test it out first. That being said, I consider many corporate “testimonials” sponsoring one OS or another based on security or other factors to be FUD, mainly because they often appear in paid advertisements and seldom reveal the details of tests performed to lead to such conclusions. Independent certification and research performed by government or other nonprofit entities are usually the most objective and reliable.

Aside from learning the code, another way to test an application’s security strength or to see if it transmits private data is to watch (or “sniff”) the port on which it communicates using a network monitoring tool. Such data may be encrypted, but the (data) size and timing of requests made by the client software should be consistent and reasonable. This is a technical task, but a bit easier than learning how the code works. Just remember, sniffing outside of your own network may be considered illegal.

Finally, there are many Linux opponents that would jump at the chance to expose real security weaknesses in Linux and its applications. These are often vendors of competing software and have both the money and channels to make themselves heard. When such a claim appears on the Web, look for specific details about the vulnerability. If there are none, it may be FUD. Also, check the software website to see if the vulnerability has been acknowledged or refuted as well as any status on its repair. Never take such claims at face value.

Here’s a few tips to remember to help protect yourself.

Any security expert worth his salt will tell you that physical security is the most important aspect of system security. If physical access to a computer is available, then it is usually just a matter of time before the system will be compromised, regardless of operating system. Obviously, the probability of such breaches skyrockets for laptop users, especially when so few (based on my own observations) choose to utilize even the most primitive of safeguards, cable locks. Also, I’ve not seen any major headlines on this so far, but Live CDs, as wonderfully useful as they can be, are ginormous threats to the security if physical access is available. This is because most Live CDs provide superuser access to a system and all of its devices. It is best to keep computers under lock & key whenever possible.

One of my friends from university used to work in an engineering lab on campus. He had set up a Linux box on the network, with full consent of the administrators of course. But one of the the permanent staff members approached him one day, asking how he managed to cloak his machine from the nightly SATAN network scans. The answer was simple! He turned the machine off before he left each day! Turning a machine off or at least disconnecting it from the Internet when not in use will deprive the would-be attacker the time needed to successfully break in using a brute force attack.

And, as always, be careful what you download. There is always a chance that someone will write spyware or malware for Linux. Stick with applications that have large communities and good reputations if you can. Search the Internet for evidence that an app may not be secure before downloading it. To quote the the Gipper, “trust, but verify”.

Cheers!
-Brandon

<< Go To Part 4 Go To Part 6 >>
Advertisements

Top 10 Linux FUD Patterns, Part 4

In this installment of my series on the Top 10 Linux FUD patterns, I address two patterns that have more to do with software packages that run on the Linux platform than with the Linux OS itself. As I stated in a previous post, every believable piece of FUD has some element of truth behind it, and these two are no exception.

Linux FUD Pattern #3: With Linux, you cannot access old files or share new files with others

Do you remember the Word Processor Wars? For those who don’t, a conflict began in the early 1990s as to which word processing application was the “best”, the most feature-rich, and the one most likely to dominate the market. It was a fight to the death. Though this was largely a war over functionality, the decisive battles were often fought on the file system. Why? Because the ability to understand and use a competitor’s file structure has certain advantages. First, almost any hot new function can be replicated because a sample of data speaks volumes about the processes that created it. Second, the ability to open and use the other format eases transition away from the other product. Proprietary file formats became the weapon of choice, and the strategy, to lock as many users into them as possible. The mentality that whoever controls the data controls the world solidified.

Except for the occasional Is-Linux-Right-For-You? article in the trades, this pattern does not manifest in print very often. It is more likely a topic hotly debated between OS zealots. Most often, I have been personally presented this tasty FUD cake by folks that have no experience with Linux or its applications, who think (through no fault of their own) that we *nix users type all of our letters and papers in on the command line. I raise the fact that OpenOffice can not only open many other document formats but that it can *cough* natively export PDF files as well, and suddenly the eighth-grade-level trash-speak subsides.

File exchange is not a myth; indeed, it is a very important issue. Moreover, for anyone who’s been watching the OOXML vs ODF standoff, it should be clear that the Open Source community is very much in favor of a set of open documentation standards as well. Whether or not it used to be, cross-platform file sharing is just not a problem with today’s desktop environments and is becoming less so.

If this is a serious concern, my advice is to either save your files in a highly-interchangeable format from the start or have an exit strategy that entails migration to another app later. HTML is one option, but only if maintaining strict page layout is of little importance. I have had better luck with the Rich Text Format (RTF); granted, this is not an open format, but it is highly portable and since it is ASCII-based mark up, I can read it with a text editor in a pinch. Also, I tend to save copies of documents in Adobe’s Portable Document Format (PDF), not just because it is portable, but because it looks more professional when sending documents to others. When I upgraded to a new machine and installed Linux for full-time use, I had to convert all of my AutoCAD Drawing (DWG) files to the Drawing Interchange Format (DXF) for use with QcaD. Between that and converting all of the Works 2.0 documents to RTF, I spent many hours executing an exit plan that could have been avoided altogether – lesson learned.

Linux FUD Pattern #4: There are no good software titles for Linux

Looking back, the title of this pattern should have been “There are no popular software titles for Linux”, but in my haste, I typed the word “good” instead of “popular”. This gives the impression that this pattern addresses the quality of Linux software, an issue to be covered later under pattern #6. My apologies.

Nonetheless, this statement – as related to the popularity of software titles – is a highly relative one. OpenOffice and Firefox are wildly popular amongst Linux users. They are bundled with nearly every major distribution and receive a lot of press. They are also available for other platforms, and though they do not dominate these market segments, they seem to be gaining popularity.

The measurement used to determine popularity is an important factor underlying this statement. Is popularity based on customer registrations? Sales? How about the rack space devoted to software at the store? All of these metrics are biased toward commercial software and against free software. Considering the number of try-before-you-buy commercial apps available, download-counting may be a tempting metric to use, but it is biased in the opposite direction and doesn’t consider anomalies such as multiple installations or the ultimate rejection of the product by users. An unbiased consumer survey may be the only way to truly determine popularity. If anyone has actually accomplished this, please share.

Another important question is, does popularity really matter? There is a link between popularity and the fear that an app will eventually lose support, but that risk can be mitigated with a good exit strategy as discussed above. That fear is the target of this FUD pattern. Also, in my opinion, computing is not a popularity contest. If a software application meets my needs and the outlook for support is favorable, then I don’t care if everyone uses it or not. Sometimes, form is more important than function and sometimes it is not, but choosing an app solely because “everyone else is using it” is rarely an acceptable strategy.

The obvious exception is high-end computer games. Computer games in general have created a special culture, and each game has a following, large or small. Games are not about functionality and meeting requirements, but about being part of the culture…shared experiences are part of the entertainment. Admittedly, there are few “big names” producing or porting popular game titles to Linux, a trend that will continue until the gaming market demands otherwise. The desire to be a member of that culture can certainly be enough to dictate which OS to use some or all of the time. Hopefully, things will change.

Finally, the statement is much too general. While it may be true in respect to high-end games, the supposed lack of software is often exaggerated to include all possible uses of the OS, creating yet more FUD.

Cheers!
-Brandon

<< Go To Part 3 Go To Part 5 >>