|
LQ Guru
Registered: Feb 2003
Location: Sparta, NC USA
Distribution: Ubuntu 10.04
Posts: 5,141
Rep: 
|
For those to lazy to click my link:
Should I get anti-virus software for my Linux box?
The problem with answering this question is that those asking it know only OSes where viruses, trojan-horse programs, worms, nasty Javascripts, ActiveX controls with destructive payloads, and ordinary misbehaved applications are a constant threat to their computing. Therefore, they refuse to believe Linux could be different, no matter what they hear.
And yet it is.
Here's the short version of the answer: No. If you simply never run untrusted executables while logged in as the root user (or equivalent), all the "virus checkers" in the world will be at best superfluous; at worst, downright harmful. "Hostile" executables (including viruses) are almost unfindable in the Linux world -- and no real threat to it -- because they lack root-user authority, and because Linux admins are seldom stupid enough to run untrusted executables as root, and because Linux users' sources for privileged executables enjoy paranoid-grade scrutiny (such that any unauthorised changes would be detected and remedied).
Here's the long version: Still no. Any program on a Linux box, viruses included, can only do what the user who ran it can do. Real users aren't allowed to hurt the system (only the root user can), so neither can programs they run.
Because of the distinction between privileged (root-run) processes and user-owned processes, a "hostile" executable that a non-root user receives (or creates) and then executes (runs) cannot "infect" or otherwise manipulate the system as a whole. Just as you can delete only your own files (i.e., those you have "write" permission to), executables you run cannot affect other users' (or root's) files. Therefore, although you can create (or retrieve), and then run, a virus, worm, trojan horse, etc., it can't do much. Unless you do so as "root". Which it's simple to avoid doing.
The first "virus" (arguably, actually a trojan or worm) for Linux was named "Bliss", created in 1997 as a proof of concept. If a user executes an infected executable, the viral code appends itself to all executables for which the user has write permission. But thereafter, it can't go anywhere else or do anything else -- and cannot take over (infect) the local machine (or any other): It lacks permission to do so. Nor can the other Linux/Unix viruses / worms / trojan horses thus far known. And claims of "Bliss" infections outside deliberate lab-only deployment by virus researchers are, in point of fact, considered suspect. New Linux viruses (such as Simile.D) emerge continually, too. But guess what? They don't go anywhere, either.
Most people asking this question have no experience with true multi-user systems built around a pervasive, ground-up security model. On their systems, any process the user executes, directly or indirectly, can modify, destroy, or manipulate anything on the system. This is true to a degree even on MS-Windows NT/XP, which tries to be fully multiuser as Unixes are, but has numerous fundamental security flaws.
By contrast, on Linux (or any other Unix), your processes cannot harm the machine (or damage other users' files) -- because you yourself cannot.
Thus, even a Linux user who deliberately wants to activate a Linux virus (trojan horse, worm, or other program designed to do mischief) will have extreme difficulty getting it to circulate. If you're a programmer, try and see. Viruses aren't difficult to write on Linux: Write one, run it (as a non-root user), and watch it bollix your files. But nobody else's.
Three objections are commonly raised to the above argument:
1) Ah, you say, all you need do is insert "hostile" code into some package that must run with root-user privileges. True, that would work: Just infiltrate the main software-distribution chains. But this is extremely difficult, not just because the distribution chain is well monitored by paranoid technical people, but also because, with open-source code, any odd modifications would be quickly found by the large number of programmers working on the source code, and removed.
With binary-only Linux software (little of which must run with root authority), e.g., packages offered by proprietary software companies, you would face the equally daunting task of adulterating the product of a company that realises such intrusions would damage its reputation (unlike in the MS-Windows market, where Microsoft Corporation has repeatedly shipped virus-infected CD-ROMs, and nobody considered that peculiar or unacceptable). Given that have you pulled off such a feat, your virus would then encounter the previously-detailed barriers to its further spread, and thus probably go roughly nowhere (beyond the systems initially infected). And then, the damaged systems would get rebuilt, and the virus would effectively die out.
2) Well then, you say, one might engineer a virus to start out as a user-owned process, but then crack the local security model from the inside. This approach, too, might work -- if it could be done unobtrusively. At any given time, some of any Linux (or other Unix) system's dozens of root-owned system binaries will undoubtedly be vulnerable to attack, but viruses and similar code must be small, simple, and unobtrusive. The two goals are incompatible.
But this brings up another reason why Linux/Unix systems tend to be hardy: genetic diversity. That is, for virus-like code to spread among Linux boxes, it must be unfazed by the variety of CPU architectures Linux supports, and their diversity of software and of configuration. As long as Linux distributions remain diverse, they will be that much harder a target.
3) Last, you say, surely sysadmins stupid enough to take dangerous actions as root must be becoming the norm instead of a rarity, given Linux's current explosive growth -- thus undermining the whole security model. This, too, is true -- but there are powerful forces at work to educate new sysadmins: The administrative tools, themselves, tend to stress that the root account is dangerous and should be used minimally and carefully, as does Linux's new-user documentation. Also, those sysadmins resistant to learning this message via such avenues inevitably learn it the hard way, by destroying or crippling their systems repeatedly -- until they learn. In that regard, viruses do not even stand out from the general likelihood of repeatedly destroying one's system, until one learns to not do unwise things as root. The difference between "hostile" executables (such as viruses) and others is academic, when a root-account user can already shoot off his foot or other vital parts, with one of myriad, brief commands. Put the other way, the same survival skills by which you, as a novice sysadmin, will cease destroying your system directly will also, more generally, dissuade you from doing unwise things as root, thereby incidentally keeping viruses and their kin off your system.
Or, put a third way, the Linux community would see no real distinction between novices who (as root) infect their systems (if this should ever happen to significant numbers of them), and those who accidentally type some variation on "rm -rf /" (delete all files) while logged in as root: Both are a result of inexperience and lack of caution. In both cases, education, attention, and experience are a 100% effective cure.
The above discussion has centred on the root user's actions, and has mostly been variations on the theme of don't run untrusted executables as root. There remains one other option: viruses (and similar things) that don't attempt to affect system binaries or take over entire machines, but instead dwell in a particular user's account and attempt to spread to other user accounts, on that or other machines, via inter-user communication mechanisms such as e-mail. One might imagine, for example, a virus written in "elisp", the macro language of GNU emacs and xemacs, and propagating as attachments to e-mail sent to other emacs users.
Such an invention would be at worst a nuisance among a few users, as it could affect only users running the same combinations of user software. Further, the Unix community long ago became wary of auto-executing programs/macros, so ultimately this technique would rely on convincing each additional user to execute (run) the program/macro, to "infect" his files. Also, in the Linux/Unix world, macros tend to be stored as readable plain text (unlike the case with, say, MS-Word), so that untrustworthy code is difficult to conceal from user scrutiny.
In these areas, again, viruses wouldn't stand out from the general category of programs another user sends you that you shouldn't run: If a friend mailed you a script that would erase all your files, would you run it? Of course not. In the same sense, you would not automatically run any other executable that landed on your doorstep, from another user -- and Linux programs will pretty reliably not auto-run them for you (nor even save them with the executable bit still present). If Linux programs emerge that do auto-execute (e.g.) macros in documents attached to e-mail (as does the combination of MS-Outlook or MS-Outlook Express with MS-Word on Win32 systems), there might be a flurry of viruses transmitted that way, until the foolishness of such a feature becomes obvious to all -- or until only fools run such programs.
Linux systems can be indirectly affected by viruses arising on more-vulnerable systems. If you offer file-sharing services from a Linux machine to others on its network, such as NFS, Samba, or NetATalk, the other machines might well store infected programs on the shared volumes. (For this reason, sometimes Linux sysadmins run checkers to catch and remove foreign OS viruses from shared files, in-transit e-mail, and the like.) Also, the Linux boot process might be interrupted by operation of (say) a virus originating in MS-Windows, and affecting boot-sensitive areas such as the Master Boot Record. But these are not Linux viruses, which remain vanishingly rare and (effectively) a harmless curiosity.
And yet. . . . And yet, the big anti-viral companies such as McAfee and Symantec all hawk anti-viral products for Linux. Why would they do this, if viruses pose no threat? Because gullible people have money, too, that's why. Such products are sold to the crowds of people who refuse to believe essays like this one. If you feel that way, buy them with pride: It's easier than thinking.
But then again, maybe you just can't trust anyone. Caveat user.
For a knowledgeable, but more glass-half-empty, view of Unix viruses, see also Rado Dejanovic's article. Also, Bruce Ediger appears to be interested in the same subject.
All this is not intended to suggest that system-integrity checkers like AIDE, Tripwire, and other IDSes aren't an excellent idea: Being able to detect unauthorised changes is a very good thing. Ditto the various schemes to "sandbox" untrusted code.
By the way, the ill-informed lucubrations of a Slashdot writer to the contrary, there is no such word as "virii". The plural of this English word is "viruses". (The word was borrowed and redefined from the Latin word virus = slime, poison, or venom. In Latin, that is a 2nd declension neuter noun, whose nominative plural form is now unclear, since it seems that nobody ever used one -- and it doesn't appear to work like either a standard "-us" or "-um" noun, whose plural behaviours are known. In other words, it doesn't have a Latin plural, possibly because it was a mass noun rather than a countable one.)
But didn't security expert Simson L. Garfinkel say that all Linux systems needed to run virus checkers?
Yes. Top security authority Garfinkel, author of Practical Unix and Internet Security and other classics, did say, in a SecurityFocus article, that a plague of viruses are destined to descend upon Linux, and that the only cure is for all Linux systems to run "credible anti-virus software".
Garfinkel acknowledges that the threat he envisions exists only because inexperienced sysadmins "are incredibly promiscuous with the root account", but he thinks running software that compensates for root-user carelessness is an appropriate and adequate remedy.
Unfortunately, this world-class authority is dead wrong: There is no way that automated "checking" software can ever prevent a careless root user from damaging (or fully destroying) the system. As explained in the prior essay, the remedy is not adequate because viruses are a very minor system threat compared to the extremely broad variety of easy ways a root-account user has of damaging/destroying his system, and that remedy is not appropriate because it fails to address the underlying, real problem of sysadmins being willing to carry out dangerous actions while logged in as the root user.
It is simply not possible to create and run a piece of software sophisticated enough to prevent a root user from running scripts, system commands, interpreted programs, or any of myriad non-virus executables having destructive potential equal to or greater than that of any virus. Further, such a program would be hostile to the very idea of a root account, which is by design supposed to be able to carry out any possible action on the system.
(And, by the way, what's going to protect you from subverted or just dangerously defective virus checkers, themselves wielding root authority? Hmm?)
The implication is clear: If a user lacks the judgement to use the root account safely, the only way to protect the system from that user is for him to not have root access. After carrying out this remedy to address the real causes of the problem, adding a "virus checker" is neither necessary nor useful.
It should be noted that there is nothing wrong with lacking the root password to one's system. Corporations do that with Unix boxes all the time. Somebody else, whom you trust to do any rare system administration tasks required, can keep and use your root password.
Is this inconvenient? Possibly. At a minimum, it requires modifying the usual PC-desktop habits of thinking -- e.g., you might have to provide security-hardened remote access to your Linux box using ssh/scp. But that is a good thing, because it allows you to deal with real, fundamental problems in an effective manner. Adopting Garfinkel's would-be solution does not accomplish that.
Don't the rise of Linux worms like Ramen, 1i0n, Red Worm, Adore, Cheese, lpdw0rm, and Slapper show that Linux now has a virus problem?
No, they demonstrate that the computer press doesn't understand network security, and reprints boilerplate self-promotion from the anti-virus industry in lieu of news and analysis. Saying these display a "virus problem" is like saying a homeowner had a "fire hazard problem" after he left his home wide open and unoccupied for six months, then burglars finally noticed the house, stole its valuables, and finally torched it.
To explain: None of these Linux worms break into systems directly, but rather perform automated "script-kiddie"-style probes for specific obsolete, security-vulnerable network daemon (server) software versions. Typically, those vulnerabilities they seek were found and fixed months or years ago -- and heavily publicised. At which point, everyone with a grain of common sense upgraded.
If you run a Linux (or other Unix) system and choose to have it offer network services, especially using overly complex, security-problematic software such as BIND v. 8 and WU-FTPd, it is an elementary fact of life that failing to heed security advisories and update your software when necessary means you may have your valuable business plans and other confidential data stolen or subtly sabotaged. You may find yourself arrested and tried for crimes you seem to have committed using your computer. You may give faceless strangers the means to believably impersonate you for their own purposes. You may see your and (sometimes) your company's reputation injured, and your career in ruins. You may suffer immense financial losses.
The point? "Linux worms" don't even rate in the catalogue of disaster you may suffer, if you have given the bad guys a dirt-easy way to seize total control of your system anonymously from anywhere in the world. Thus, people who fixate on the (at best) adding-insult-to-injury threat of "Linux worms" do not understand the subject of real network security at all.
For the sake of completeness, I should also mention that there's nothing Linux-specific about those "worms": Since the attack is against long-notorious vulnerabilities in widely-used network daemon software, they can be trivially modified to find and exploit such holes on other platforms where those packages run. But really, even that runs the risk of obscuring the real point: "Worm" attacks are not themselves a security issue, but rather one of the lesser consequences that typically result from ignoring real security issues for ludicrous lengths of time.
Isn't Microsoft Corporation's market dominance, making Linux an insignificant target, the only reason it doesn't have a virus problem?
Not at all. This question is virus pundits' pons asinorum: If they can't think past this fallacy, don't even try to reason with them, as they're hopelessly mired in rationalisation.
The speaker's supposition is that virus writers will (like himself) ignore anything the least bit unfamiliar, and attack only the most-common user software and operating systems, thus explaining why Unix viruses are essentially unknown in the field. This is doubly fallacious: 1. It ignores Unix's dominance in a number of non-desktop specialties, including Web servers and scientific workstations. A virus/trojan/worm author who successfully targeted specifically Apache Linux/x86 Web servers would both have an extremely target-rich environment and instantly earn lasting fame, and yet it doesn't happen.
2. Even aside from that, it completely fails to account for observed fact: Assume that only 1% of Internet-reachable hosts run x86 Linux (a conservative figure). Assume that only one virus writer out of 1000 targets Unixes. Then, given the near-instant communication across the Net that at this writing is blitzing my Linux Web server with dozens of futile probes for the Microsoft "Nimda" vulnerability per second, the product of that one virus writer's work should be a nagging problem on Linux machines everywhere -- and he'll be working very hard to achieve that, given the bragging rights he would gain. Yet, it's not there. Where is it?
The answer is that, for various reasons discussed in prior essays, such code is very easy to write, but completely impractical to propagate. And likely to remain so.
|
they are just not as common, but they do exist...so in turn yes, there is always a chance...not as much but there still is...
