Mainstream means more malicious code for Linux (SearchSecurity.com)

I agree with the conclusion that the incentive for writing Linux virusses will become larger when Linux is deployed on a larger scale. But will that lead to Microsoft scale epidemics? I doubt that.

Uh, wait a minute. If this is the premise, then why does the discussion that follows primarily discuss server-side exploits against Apache, which out numbers IIS on the Internet by at least 2 to 1 (and has for some time now). I think the author is confusing two seperate issues here: server-side vulnerabilities, and client-side vulnerabilities.

I have deployed Linux on the desktop (RH8+Ximian to RH9+StarOffice) in an enterprise and they do not suffer from such problems for long.
1) The only network service the desktop systems expose is OpenSSH and the Iptables limit access from only three addresses.( We use a custom script with ssh to keep the systems rpms uptodate from a private mirror).
2) The iptables are configured to allow the desktops client services to connect only to the specified server.
3) The /usr partions are mounted read only and the /tmp, /home, /var directories are mounted non executable.
4) None of the users have, or need, root access. They have access to printer setting etc via Webmin's Usermin which runs on a dedicated server.
5) Mounting the users home directory required shares etc ( we use Samba for domain, file and print services ) is performed by script when the user logs in.
6) We update all the desktops within minutes of a updated RPM package becoming available. The window of opportunity for any disclosed vulnerability is very small.
7) We schedule Tripwire to check the intergrity of the desktops a couple time a day.

Windows was built on top of a fundamentally insecure operating system, It needs to keep much backward compatability with executables from that system, even though its designers have since moved on to (bolted on? retrofitted?) more secure underlying code. Because of this, the basic coding operations for viruses applies to *all* Windows platforms. The only thing the writers had to do was learn where the additional safeguards were, where the differences were between 16-bit and 32-bit code, etc.

In the Netware days, viruses got around an enterprise because the OS acted like a "carrier", but was not itself infected. If Windows executables are being loaded *from* a Linux box through SMB, then the Linux box becomes a carrier. If the Linux box is capable of serving up OLE and all that other stuff, then it also becomes a carrier by that route.

But if you use a fundamentally similar OS on the server, then, voila, the server becomes prone to infections as well, as soon as the virus writers learn how to scratch it in the right place.

I have held (and still hold) these views about Windows: that it has fundamental design flaws that make it inherrently insecure. Whether Linux becomes a target for malicious code or not, I don't see that fundamental security issue on Linux. I do see that certain people are goingt to SCREAM as loudly as possible, however, every time any little tiny Linux break-in happens, thinking that such loudness will somehow make *their* OS more appealing, when instead we all should be spending a little more time putting the thieves in jail where they belong.

What's the point? I tried to get some of these ideas across to my bosses *before* we went to an NT platform. If I couldn't get them across to my own management, how will a reporter get them right?

Certainly Linux is vulnerable, and will become a more attractive target of the black hats as its popularity increases.

That said, we should reject the solutions offered by the anti-virus companies. Real security does not fit their business model, since its purpose is to extract maximum cash from the public, and actually preventing all malware would not do that. They would rather do what they do now, which is to offer their customers a list of "known criminals" to check against, which has the virtue (from their point of view) of requiring a subscription so that their customers can keep current, but does not interfere in the least with the ability of virus writers to write new malware, thereby generating new business for the anti-virus companies.

I see multiple demonstrations of the lack of ethics of some anti-virus companies every day, every time I see a bounce of one of the current crop of email viruses, followed by a warning that I am infected, saying that I have some anti-virus company's mail filter to thank for this "service" and strongly suggesting that I need to buy such a product to be safe. Of course, the designers of these mail filters know full well that the return address is forged, but they happily spam me anyway.

What we need to do instead is take a systems approach, focusing on eliminating whole classes of attacks. The Gnome and KDE teams need to be sure, when cloning features of Windows, to avoid cloning those features that are demonstrated to be vulnerabilities. No hiding of file extensions in an attempt to be "friendly". No self-extracting archive formats that basically tell the user to run an untrusted program. "Taint" analysis to be really paranoid about untrusted data. Audit libraries to the point where we can mathematically prove, say, that the conversion from a JPEG or PNG to a bitmap/pixmap for use in an application contains no buffer overflows, and work to continually increase the amount of trusted code.

And if a feature could conceivably be unsafe, work hard to make it safe or leave it out. And when the bugs come anyway, fix them quickly.

However, that grain is suspended in a large greasy globule of FUD.

We (the FOSS, free and open source software communities) don't have to tolerate software or hardware monocultures. We can run Linux *and* any of the various *BSD flavors; we can run Linux (or NetBSD or OpenBSD) on many other hardware architectures; we can run alternatives to almost any software (many web servers, at least 4 major MTAs, a handful of DNS servers, even alternatives to sshd and for time synchronization). And there exist a number of different kernel security hardening patches (LIDS, GRSecurity, LOMAC, RSBAC, SELinux, syslinux, etc).

So, no single bug need threaten more than a minority of us.

Also the modularity and process protection model in Linux is substantially more effective than the practice evident in Microsoft's Windows OS, IIS, Exchange and other products. Theoretically they offer more elaborate protections in the OS, but in practice their own code is given permission to penetrate so many of these isolation semantics that the theory is practically a lie.

If someone breaks my Apache processes with a remote, arbitrary code exploit, they've gained access to "Mr. Webserver" The default installation and configuration of Linux somewhat limits what "Mr. Webserver" can do to the rest of the system and a competent, professional Linux system administrator will routinely tighten that up much more.

Competent systems administration makes a huge difference in either case. However, I would argue that a competent UNIX or Linux systems administrator can have a much greater impact on the security, stability and performance of their systems than a comparably trained and experienced NT/W2K/XP/ME administrator.

For instance I can easily lock down sshd so that connections are only accepted from specific hosts, so that passwords are never accepted, public/private keypairs are required, so that specific accounts can only be used to execute specific commands, and so that there are multiple levels of this protection going on (through iptables/ipchains/ipfwadm *and* the TCP Wrappers and internal hosts ACLs in sshd itself, as well as with chroot jails, systrace wrappers, etc). I routinely lock down my servers to only permit a couple of specific "management stations" to access their ssh services; and I set up liaison systems which are similarly restricted for transferring data to and from "business partners" (or vendors and customers).

That's a simple example, but it means that a bug in sshd can't spread directly from an arbitrary attacker or compromised system into my systems. The liaison systems become vulnerable only after one of my partners, vendors or strategic customers is compromised and that vulnerability is still limited to a chroot jail and a non-root account (probably) while my servers are secure until my internal management stations are compromised. In other words it's easy to put in these "firestops." (In the construction trades a firewall is a wall that extends from foundation to the roof and from one exterior wall to another, a firestop is a block of material, usually wood, between studs within a wall to limit and slow the spread of a file up through the inside of a wall --- reduce the drafting through wall segments which would otherwise act as chimneys, drawing oxygen more quickly and causing the fire to burn hotter).

By simply limiting the peers to protocols like ssh, snmp, and NTP we mitigate some of the risks that these privileged pockets of software monoculture pose. That's why I refer to them as firestops.

As another example we generally configure a small set of border NTP servers which can only receive NTP peering traffic from a limited set of external sources, sometimes we isolate those with a "protocol lock" using rdate across the firewall rather than NTP. Then the interior systems only use NTP to the internal NTP servers. In any case only a limited number of external hosts could exploit an NTP bug to compromise a border system. If a protocol lock is employed then a different bug (one that can propagate through this alternative time synchronization protocol) must be used to get through it. Even without that the systems administrators have time to be alerted to the problem and to temporarily block that service, update the border systems, etc. (Also it's notable that there are patches to the stock xntpd that use the Linux "capabilities" (from the POSIX.1e draft proposal) to allow that daemon to run as "nobody" with only the permissions necessary to adjust the system time --- it's also possible to write a trivial wrapper around xntpd using the lcap/lcap2 package (with sucap or execcap).

Using systrace to jail programs like xntpd, BIND (named) etc is even better, somewhat easier, and is portable to OpenBSD/NetBSD, and MacOS X
as well. I would like to see it deployed more widely and adopted as a tool across all versions of UNIX.

Granted that are far too few sites, distributions and software packages that are making use of all these techniques and options. However, the features exist for Linux, the knowlege is readily available, and the tools are free for the taking.

Jim

Fact of the matter is, everything built by Man (or Woman) is imperfect; there always will be security weaknesses, and some of them will inevitably be exploited in the real world. Nevertheless Windows has always had a "security" policy based on obscurity and a pack-everything-in-and-obfuscate (by deep application links into the kernel) design philosophy. The open source model (make source code avaiable for peer review, make every application do one thing only but do it well, maintain a clear distinction between OS kernel and application) is so obviously better that I really don't see that there is much of a case to answer.

However, despite this wonderful piece of FUD, we can't be complacent - software designers need to "think secure", and the peer review really needs to be done, not just paid lip service to.

Of course, securing a system connected to the internet requires more effort than simply accepting the default firewall settings. Maybe Windows' point&click interface for configuring (internet-)services made it too easy for sysadmins to deploy an insecure system.

Email viruses are not a threat to Linux-based desktops, for several reasons:
- there is no single email application for Linux, like Outlook and O-Express for Windows. Most people seem to use Ximian Evolution, but I don't know how many. So all the viruses that specifically exploit Outlook vulnarabilities (like hiding filename extensions, or buffer overflows in the preview pane) won't impact alternative email clients. Some email viruses use Outlook's address book to forward themselves, but this would be very hard to do on Linux because it lacks a common address book service (however the Gnome project seems to be working on it).
- Even if a virus would run, only the user's home directory (and maybe a few others, like /tmp, which can be emptied anyway on every reboot) could be affected. It is easy to setup a new, clean account, transfer all documents (non-binary, human-readable document formats are very hard to turn into virus-carriers) to the new account, copy the program settings and email, and delete the infected account. This could easily be automated using a friendly wizard.

Most virus-scanner companies will find a way to sell their stuff anyway. Most people know that running a decent antivirus program on Windows is important, and wouldn't trust a system without it.