This works for books as well. Eric Flint and other authors reported increased sales after they had some books released for free on the Baen Free Library.
Including paper copies of the same novels they'd released as free eBooks!
It's not just a matter of it not being "as good", or "not as easily fixed", it's a matter of the basic design of the program is such that no amount of fixing or improving the code without changing the design and making it incompatible with existing applications can solve the problems. Windows applications expect to have a rich set of APIs available to them, involving unencumbered communication with many components that are not intended to be secure in the way a webserver has to be. UNIX applications expect to operate though a small set of well defined APIs designed around an opaque file handle... on the other side of which is alien and untrusted territory. Windows applications grew up in an environment where EVERYTHING on the same computer is implicitly trusted. UNIX applications grew up in an environment where you had things like... students writing papers and teachers grading papers on the same computer.
Apple removed the One True VI from Panther and replaced it with that sorry compromise "VIM", which was probably written by an Emacs user. And not a REAL Emacs user, no, I'll bet they were using Lucid Emacs or something.
(Actually, to make full disclosure, I wrote some of the code that ended up in vim. Ironic, wot?)
The shell, print spooler, local web server, all the security components, the equivalents of virtually all Windows services and registry, basically every command line application or daemon is there. Not a lot of the GUI, with the exception of WebCore, but a hell of a lot more than just the kernel, and the corresponding components to most of the parts of Windows that have been big security problems: RPC, HTML and HTTP, IIS, CMD.EXE and the Registry, remote file access and file-and-print service, it's all in there.
Safari and Dashboard are the bits I'm most worried about in OS X. WebCore is there, and the parts of them that aren't in WebCore are pretty thin shell layers (in fact they've been re-implemented by third parties). The biggest component left out that doesn't seem to be covered is LaunchServices (not launchd, that's an unrelated coincidence), and you can limit your exposure to any LaunchServices-related issues by disabling "Open Safe Files after Downloading" in Safari.
Both companies pursue that old-fashioned model of closing their codebases and asking developers to sign NDA's.
Here is the source to WebCore as shipped with OS X 10.4.4, which is Apple's equivalent to Microsoft's HTML control. Now, this is kind of an important part of the OS from the point of view of security, since Microsoft's HTML control is by far the biggest security problem in the Windows world, and has been since 1997. The BSD core, everything you need to get to a self-hosting OS with login and user-account security, is in the tree at opendarwin.org. From the point of view of a security analysis, the difference between Microsoft and Apple's openness is pretty much as wide as you can get between two software companies.
Oh, certainly, there's a lot of OS X that isn't as open as this... but even the closed parts are amazingly transparent and easily understood compared to Windows, and no important part of Windows is open at all.
one current example of this is the fact that MS IIS is a fraction of its market compared to Apache, but that IIS gets a disproportionately large amount of attacks compared to Apache (which receives a very tiny number of attacks).
This is also due to the fact that IIS has poor internal security design: the local parts of URLs are parsed multiple times where Apache maintains them intact, and there are few tools in IIS or Windows to establish internal privilege separation of the kind that comes naturally to UNIX and Apache.
No wonder he's worried about Mac users being naive about security, when he writes "The security model in Unix-based operating systems like Darwin means that it is very hard to see how an infection could spread, even if an executable could be compromised."
The main reason that Mac OS X is more secure than Windows is that Mac OS X has a smaller surface area exposed to attack, but it has a smaller surface area exposed to attack than most default Linux distros, or most historical networked UNIX systems... and the main reason it's got a smaller surface area exposed to attack is because of the way the browser works... not because of the UNIX roots of OS X. Browsers on OS 9 were also safer than on Windows, and for the same reason.
Once an executable is compromised, it's little harder to transmit an email virus or set up a trojan horse in OS X than in Windows. You don't need "root" to send email or listen on a high port or sneak a credible-sounding backdoor program into a user's login preferences.
A bit of protection from the madness of others, that's all I'm asking for.
Fair enough, but what does that have to do with Perl?
If you want a sane language, ECMAscript (nee Javascript nee Livescript) is probably the sanest language in general use today. Yes, yes, I know web browsers are terribly unsane environments, but poor old *script does a man's work in that sewer... it's got a lovely template-based class model, and if the class libraries it has to deal with are bloody awful that's not its fault.
Give us a command-line ECMAscript with a sane texthacking class library, and call it Perl 7. You know it's the right thing to do.:)
Try to break in, then. Seriously, how would you do it?
I haven't got an OS 9 box at hand, but I'd apply the same kinds of general techniques that I'd use to attack a Windows box, depending on the fact that all the major web browsers and email applications on OS 9 automatically open downloaded files and attachments. It's not quite as easy as shoving a code segment in a resource fork like you could in System 6, but it's still got a plethora of attack vectors.
Yes, it's unlikely at this date that anyone would bother... but that's got nothing to do with the security of the OS itself.
There's no command line to pipe commands or run scripts.
Applescript is far more powerful and versatile than command.com or cmd.exe, and consing up a little code segment to kick off an Applescript payload once you've got instructions under the CPU (either PPC code or 68000 code) isn't rough.
People have offered cash prizes and published the exact (static) address to Mac servers
"Hacker Challenges" tell you nothing about the security of the OS. I could set up a Windows box that had no exposed surface area on the Internet, and it would still be the same virus-reservoir so long as I was using Internet Explorer and Outlook and pounding on the keyboard like a monkey on crack... the way (in my experience) naive computer users (whether using Mac OS or Windows) are wont to do.
With OSX Apple took a deliberate step towards what has the potential to be a less secure OS
Or a more secure one. It doesn't ship with any non-local services enabled, it actually has local security, and it doesn't have as much legacy support even with Classic enabled and OS 9 installed. It could be used or abused in ways that can turn EITHER potential into reality, but it starts off from a sounder base.
I don't think Apple will ever ship a pure 64-bit G5 OS. It would be slower than the 32-bit version, and since it's a lame duck now there's not really any point.
Intel has spent many years dealing with register starvation and they make excellent use of register renaming to deal with context switching.
I'm sure they're doing the very best they can with their crippled architecture, but they can't do much about the laws of physics. Despite spending massive amounts of time and money, not to mention transistors and chip area, their processors don't display the kinds of performance they should be able to manage with that kind of budget.
As for IA64, Intel has a long history of being hopeless incompetants at instruction set design, a grand tradition that goes far beyond the dysfunctional 80*86 family and includes true-blue eccentrics like the 4004, the iApx432 and the i860, and of course today's IA64. The closest thing to a decent modern chip they've done is the i960... which they promptly caponised and relegated to the embedded market lest it compete with their precious x86.
So... no matter how well Intel has done, they could hardly help but do even better if they could leave at least some of the handicaps of the x86 behind. The question is... will they?
"so they took the existing P4 'netburst' core and added instructions to the microcode that let it break-down and process AMD's 64-bit instructions"
OK, so this comment has nothing to do with Yonah/Core Duo/any future Intel chips, since there's absolutely no similarity between the P4 and PIII cores and none of the changes in the P4 core will be applicable to the PIII-based chips they'll be coming out with in the future.
Since the Power architecture doesn't have any really crippling shortcomings like the x86 small register file, the 64-bitness of the G5 is more a marketing advantage than a practical one... the number of people who need and can use large address space on the G5 can probably be counted on the fingers of one foot.
Not that many people actually need 64-bit capabilitity, mostly for programs that need very large memory access.
The main advantage of AMD64 is not the 64 bit address space, it's the larger register file. The small register file of the x86 family really cripples it: register renaming can be used to hide some dependancies and avoid bubbles in the pipeline, but the renaming has to operate in real-time over a tiny instruction window, and the compiler still has to generate (and the CPU still has to execute) code to shuffle data into and out of memory... and hitting even L1 cache has a cost.
Normally you would expect a processor with a real 32-bit and 64-bit mode to run faster in the 32-bit mode, because it's moving less data. The only exceptions to this are when the 32-bit mode is somehow crippled. For example, on the Alpha 32-bit code still has to wait on 64-bit operations and memory transfers behind the scenes. And for Intel processors, the x86 instruction set is crippled by the small register file.
And THAT is why people want 64-bit modes in their Intel processors, because they're faster and more efficient... even on otherwise 32-bit code... for reasons having nothing to do with their larger address space.
There have been some gaping holes in MacOS-X browsers that allowed execution of remote code.
I'm not sure that this is an accurate description of reality.
The use of LaunchServices by the browser without human intervention allowed for the exploit of insecure applications. The problem is that LaunchServices is used internally by applications that are never intended to be run with untrusted documents. This is a problem on Windows, and has been a problem on X11-based browsers on UNIX systems as well.
Apple has attempted to address this problem by modifying LaunchServices to alert the user when opening a URL with an application they have previously not used, and by adding warning dialogs to Safari. I believe this is the wrong approach, because it still makes social engineering attacks easier, and because it doesn't help against attacks on components that have already been used to open documents via URLs... and it causes other problems. I had the user interface lock up on me because a screensaver was attempting to use LaunchServices to run an application (legitimately), but I wasn't able to see the warning dialog because the screensaver was running.
The right approach would be for applications registered with LaunchServices to register whether they should be considered "safe" for potentially untrusted content, either via a flag (that defaults to off for existing applications, but which a user can change through Preferences) or by creating a separate WebServices registry. Applications that handle untrusted documents would use this alternate registry or attribute to avoid passing documents to innocent code. This would limit the potential for social engineering without causing problems with applications using LaunchServices internally.
However, the "surface area" of this attack is far smaller than that of Microsoft's active content. It still requires a user to explicitly visit a web page: there's no mechanism for an email message or code surreptitiously inserted into an otherwise innocent web page (say, via embedded HTML in a forum message) to automatically trigger the execution of untrusted code as there is for Outlook and Internet Explorer and other programs that use the Microsoft HTML control.
Automatic execution of native code is the "best" possible attack vector for viruses. That's why Mac viruses used to be so prevalent... it was possible to hide code fragments in the resource fork of documents and have them automatically execute when a document was opened or even displayed in Finder, similar to the way code fragments can be hidden in Windows Metafile format images. This mechanism was increasingly discouraged, and since OS X doesn't support 68000 code segments at all (not even under Classic) it's no longer an issue. Apple has steadily moved away from automatic execution of code, unfortunately Microsoft doesn't seem to have learned that this is a bad thing.
As for Cowhand... it's not an exploit, it's a payload that can be installed in an already compromised computer. Nobody would argue that you can't install backdoors in Mac OS X or any other OS, once a security flaw has been found and exploited, but the existence of a backdoor is not proof of a security flaw... and so far as I know nobody has traced Cowhand's presence back to anything but a social engineering or local (physical access, guessed passwords, etc...) attack.
I advise against buying antivirus software for the Mac. Antivirus software by its very nature can only reduce the reliability of your system, and since it's purely a responsive mechanism it can actually create a sense of complacency that makes viruses grow faster during the period before the virus is detected and a signature file is distributed.
Simply disabling any auto-execute mechanisms and being careful about who you share digital bodily fluids with works much better.
If the worst problem you can find in Mac OS X is that it allows social engineering attacks, well, that means it's even stronger than I'd give it credit for. Social engineering is not an exploit against the OS, it's an exploit against the user. You can't solve THAT technically, at least not until the Singularity when we can apply service packs on our neumonal implants.
Use a firewall, backup regularly, and don't open executables from untrusted sources. That's my whole regime.
Before 1997 that was good enough on Windows, too.
If you don't use Internet Explorer or any other application that uses the HTML control to access the Internet, that's probably STILL good enough on Windows. Be careful, because that means you don't use Realplayer, Windows Media Player, Outlook, and a lot of other applications as well as Internet Explorer.
This is to date the closest that Apple has come to the kind of horrorshow that Microsoft created back around 1997 when they integrated IE and Windows Explorer, and it's not very close at all. This hole could never be used to create an automatically propogating worm, the most it does is make social engineering attacks easier.
If social engineering was all we had to watch out for, like it pretty much was back in the early '90s when Microsoft turned the self-propogating email worm from a joke (the "GOOD TIMES" virus hoax) to reality, I'd be a happy camper.
Linux is a damned secure OS, at least as good as MacOS X.
Properly configured a Linux box, a BSD box, and a Mac should be comparably secure.
The problem is that you don't know what "Linux" a Linux is. Most Linux distributions I've used shipped with a lot of dubious software installed and enabled by default. Mac OS X isn't exactly at the level of paranoia of OpenBSD... not everything is turned off by default... but it comes with most of the "relatively paranoid security measures" already taken by Apple before they ship it.
GUI-level alerts like, "The file you're downloading contains a program, are you sure you want it?" and "This program is trying to launch for the first time, do you want it to?"
This is actually a step backwards in security. Internet Explorer on Windows now pops up some of the same dialogs, in many cases, and I have had several users come to me multiple times saying "I clicked on 'yes' accidentaly and now I think I have a virus"... because these dialogs come up often enough that people get trained into automatically clicking "yes". I've never had anyone come to me more than once with a story like "I downloaded a file, and then I opened it, and now I think I have a virus"... because downloading a file and opening it are sufficiently separate operations that you don't get trained into automatically clicking "open"... even in a download manager rather than on the desktop.
It would be much better for Safari to NOT automatically open downloaded files, and for LaunchServices to force applications that wanted to be treated as helpers for downloaded files to explicitly register as such, so that by default URLs like "x-man-page:" and "help:" would only be usable by applications directly rather than having the browser assume that any registered application was safe.
More important is that the browser has no built-in mechanism to perform unsafe actions, so it isn't possible to trick it into thinking a document is in a more trusted "zone" and automatically running it as a local user. The whole "security zone" model is so deeeply and fundamentally wrong that I'm still amazed Microsoft uses it.
But there is simply no suitable vector, akin to similar past (or present) vectors on Windows, for mass-propagation of any type of malware.
I think this is possibly exaggerating the case a little bit, because "social engineering" remains a vector... one that's disturbingly successful... and the way Safari interacts with LaunchServices by default makes social engineering easier than it should be. However, you're correct that there's no equivalent to Microsoft's security zone fiasco that makes automatic infection and mass-propogation of malware so easy on Windows.
If Mac OS X instead of Windows was the majority OS, the virus and worm problem would be no worse than it was in the early '90s before Microsoft integrated Internet Explorer with the Windows desktop and Outlook. Remember back when disabling any kind of mechanism to automatically open attachments or links, and not downloading pirated software, was usually good enough for avoiding infection?
OS9 was (and still is) a much more secure OS than OSX; it may well be amongst the most secure ever widely deployed by anyone.
Mac OS 9 has no local security at all: there's no mechanism in OS 9 to prevent any remote exploit from becoming a privileged exploit. How do you figure that it was "more secure" than OS X?
Slashdot Mirror
This works for books as well. Eric Flint and other authors reported increased sales after they had some books released for free on the Baen Free Library.
Including paper copies of the same novels they'd released as free eBooks!
It's not just a matter of it not being "as good", or "not as easily fixed", it's a matter of the basic design of the program is such that no amount of fixing or improving the code without changing the design and making it incompatible with existing applications can solve the problems. Windows applications expect to have a rich set of APIs available to them, involving unencumbered communication with many components that are not intended to be secure in the way a webserver has to be. UNIX applications expect to operate though a small set of well defined APIs designed around an opaque file handle... on the other side of which is alien and untrusted territory. Windows applications grew up in an environment where EVERYTHING on the same computer is implicitly trusted. UNIX applications grew up in an environment where you had things like... students writing papers and teachers grading papers on the same computer.
Apple removed the One True VI from Panther and replaced it with that sorry compromise "VIM", which was probably written by an Emacs user. And not a REAL Emacs user, no, I'll bet they were using Lucid Emacs or something.
(Actually, to make full disclosure, I wrote some of the code that ended up in vim. Ironic, wot?)
Only the kernel, Darwin, is opensource, but what about the application layer?
WebCore, the majority of both Safari and Dashboard, is here.
OpenSSH, remote login.
launchd, system startup and configuration.
The shell, print spooler, local web server, all the security components, the equivalents of virtually all Windows services and registry, basically every command line application or daemon is there. Not a lot of the GUI, with the exception of WebCore, but a hell of a lot more than just the kernel, and the corresponding components to most of the parts of Windows that have been big security problems: RPC, HTML and HTTP, IIS, CMD.EXE and the Registry, remote file access and file-and-print service, it's all in there.
Safari and Dashboard are the bits I'm most worried about in OS X. WebCore is there, and the parts of them that aren't in WebCore are pretty thin shell layers (in fact they've been re-implemented by third parties). The biggest component left out that doesn't seem to be covered is LaunchServices (not launchd, that's an unrelated coincidence), and you can limit your exposure to any LaunchServices-related issues by disabling "Open Safe Files after Downloading" in Safari.
Both companies pursue that old-fashioned model of closing their codebases and asking developers to sign NDA's.
Here is the source to WebCore as shipped with OS X 10.4.4, which is Apple's equivalent to Microsoft's HTML control. Now, this is kind of an important part of the OS from the point of view of security, since Microsoft's HTML control is by far the biggest security problem in the Windows world, and has been since 1997. The BSD core, everything you need to get to a self-hosting OS with login and user-account security, is in the tree at opendarwin.org. From the point of view of a security analysis, the difference between Microsoft and Apple's openness is pretty much as wide as you can get between two software companies.
Oh, certainly, there's a lot of OS X that isn't as open as this... but even the closed parts are amazingly transparent and easily understood compared to Windows, and no important part of Windows is open at all.
one current example of this is the fact that MS IIS is a fraction of its market compared to Apache, but that IIS gets a disproportionately large amount of attacks compared to Apache (which receives a very tiny number of attacks).
This is also due to the fact that IIS has poor internal security design: the local parts of URLs are parsed multiple times where Apache maintains them intact, and there are few tools in IIS or Windows to establish internal privilege separation of the kind that comes naturally to UNIX and Apache.
No wonder he's worried about Mac users being naive about security, when he writes "The security model in Unix-based operating systems like Darwin means that it is very hard to see how an infection could spread, even if an executable could be compromised."
The main reason that Mac OS X is more secure than Windows is that Mac OS X has a smaller surface area exposed to attack, but it has a smaller surface area exposed to attack than most default Linux distros, or most historical networked UNIX systems... and the main reason it's got a smaller surface area exposed to attack is because of the way the browser works... not because of the UNIX roots of OS X. Browsers on OS 9 were also safer than on Windows, and for the same reason.
Once an executable is compromised, it's little harder to transmit an email virus or set up a trojan horse in OS X than in Windows. You don't need "root" to send email or listen on a high port or sneak a credible-sounding backdoor program into a user's login preferences.
A bit of protection from the madness of others, that's all I'm asking for.
:)
Fair enough, but what does that have to do with Perl?
If you want a sane language, ECMAscript (nee Javascript nee Livescript) is probably the sanest language in general use today. Yes, yes, I know web browsers are terribly unsane environments, but poor old *script does a man's work in that sewer... it's got a lovely template-based class model, and if the class libraries it has to deal with are bloody awful that's not its fault.
Give us a command-line ECMAscript with a sane texthacking class library, and call it Perl 7. You know it's the right thing to do.
Try to break in, then. Seriously, how would you do it?
I haven't got an OS 9 box at hand, but I'd apply the same kinds of general techniques that I'd use to attack a Windows box, depending on the fact that all the major web browsers and email applications on OS 9 automatically open downloaded files and attachments. It's not quite as easy as shoving a code segment in a resource fork like you could in System 6, but it's still got a plethora of attack vectors.
Yes, it's unlikely at this date that anyone would bother... but that's got nothing to do with the security of the OS itself.
There's no command line to pipe commands or run scripts.
Applescript is far more powerful and versatile than command.com or cmd.exe, and consing up a little code segment to kick off an Applescript payload once you've got instructions under the CPU (either PPC code or 68000 code) isn't rough.
People have offered cash prizes and published the exact (static) address to Mac servers
"Hacker Challenges" tell you nothing about the security of the OS. I could set up a Windows box that had no exposed surface area on the Internet, and it would still be the same virus-reservoir so long as I was using Internet Explorer and Outlook and pounding on the keyboard like a monkey on crack... the way (in my experience) naive computer users (whether using Mac OS or Windows) are wont to do.
With OSX Apple took a deliberate step towards what has the potential to be a less secure OS
Or a more secure one. It doesn't ship with any non-local services enabled, it actually has local security, and it doesn't have as much legacy support even with Classic enabled and OS 9 installed. It could be used or abused in ways that can turn EITHER potential into reality, but it starts off from a sounder base.
I don't think Apple will ever ship a pure 64-bit G5 OS. It would be slower than the 32-bit version, and since it's a lame duck now there's not really any point.
Intel has spent many years dealing with register starvation and they make excellent use of register renaming to deal with context switching.
I'm sure they're doing the very best they can with their crippled architecture, but they can't do much about the laws of physics. Despite spending massive amounts of time and money, not to mention transistors and chip area, their processors don't display the kinds of performance they should be able to manage with that kind of budget.
As for IA64, Intel has a long history of being hopeless incompetants at instruction set design, a grand tradition that goes far beyond the dysfunctional 80*86 family and includes true-blue eccentrics like the 4004, the iApx432 and the i860, and of course today's IA64. The closest thing to a decent modern chip they've done is the i960... which they promptly caponised and relegated to the embedded market lest it compete with their precious x86.
So... no matter how well Intel has done, they could hardly help but do even better if they could leave at least some of the handicaps of the x86 behind. The question is... will they?
"so they took the existing P4 'netburst' core and added instructions to the microcode that let it break-down and process AMD's 64-bit instructions"
OK, so this comment has nothing to do with Yonah/Core Duo/any future Intel chips, since there's absolutely no similarity between the P4 and PIII cores and none of the changes in the P4 core will be applicable to the PIII-based chips they'll be coming out with in the future.
Since the Power architecture doesn't have any really crippling shortcomings like the x86 small register file, the 64-bitness of the G5 is more a marketing advantage than a practical one... the number of people who need and can use large address space on the G5 can probably be counted on the fingers of one foot.
Whether this guy or the grandparent poster is correct, this should be modded "Informative".
Intel's AMD64 instruction set is SLOWER than their IA32 instruction set.
You're pulling our legs. Please tell us you're pulling our legs. No?
Intel managed to make an AMD64-compatible processor that couldn't take advantage of the larger register file?
Remind us why Apple decided these clowns were the bees knees again?
Not that many people actually need 64-bit capabilitity, mostly for programs that need very large memory access.
The main advantage of AMD64 is not the 64 bit address space, it's the larger register file. The small register file of the x86 family really cripples it: register renaming can be used to hide some dependancies and avoid bubbles in the pipeline, but the renaming has to operate in real-time over a tiny instruction window, and the compiler still has to generate (and the CPU still has to execute) code to shuffle data into and out of memory... and hitting even L1 cache has a cost.
Normally you would expect a processor with a real 32-bit and 64-bit mode to run faster in the 32-bit mode, because it's moving less data. The only exceptions to this are when the 32-bit mode is somehow crippled. For example, on the Alpha 32-bit code still has to wait on 64-bit operations and memory transfers behind the scenes. And for Intel processors, the x86 instruction set is crippled by the small register file.
And THAT is why people want 64-bit modes in their Intel processors, because they're faster and more efficient... even on otherwise 32-bit code... for reasons having nothing to do with their larger address space.
There have been some gaping holes in MacOS-X browsers that allowed execution of remote code.
I'm not sure that this is an accurate description of reality.
The use of LaunchServices by the browser without human intervention allowed for the exploit of insecure applications. The problem is that LaunchServices is used internally by applications that are never intended to be run with untrusted documents. This is a problem on Windows, and has been a problem on X11-based browsers on UNIX systems as well.
Apple has attempted to address this problem by modifying LaunchServices to alert the user when opening a URL with an application they have previously not used, and by adding warning dialogs to Safari. I believe this is the wrong approach, because it still makes social engineering attacks easier, and because it doesn't help against attacks on components that have already been used to open documents via URLs... and it causes other problems. I had the user interface lock up on me because a screensaver was attempting to use LaunchServices to run an application (legitimately), but I wasn't able to see the warning dialog because the screensaver was running.
The right approach would be for applications registered with LaunchServices to register whether they should be considered "safe" for potentially untrusted content, either via a flag (that defaults to off for existing applications, but which a user can change through Preferences) or by creating a separate WebServices registry. Applications that handle untrusted documents would use this alternate registry or attribute to avoid passing documents to innocent code. This would limit the potential for social engineering without causing problems with applications using LaunchServices internally.
However, the "surface area" of this attack is far smaller than that of Microsoft's active content. It still requires a user to explicitly visit a web page: there's no mechanism for an email message or code surreptitiously inserted into an otherwise innocent web page (say, via embedded HTML in a forum message) to automatically trigger the execution of untrusted code as there is for Outlook and Internet Explorer and other programs that use the Microsoft HTML control.
Automatic execution of native code is the "best" possible attack vector for viruses. That's why Mac viruses used to be so prevalent... it was possible to hide code fragments in the resource fork of documents and have them automatically execute when a document was opened or even displayed in Finder, similar to the way code fragments can be hidden in Windows Metafile format images. This mechanism was increasingly discouraged, and since OS X doesn't support 68000 code segments at all (not even under Classic) it's no longer an issue. Apple has steadily moved away from automatic execution of code, unfortunately Microsoft doesn't seem to have learned that this is a bad thing.
As for Cowhand... it's not an exploit, it's a payload that can be installed in an already compromised computer. Nobody would argue that you can't install backdoors in Mac OS X or any other OS, once a security flaw has been found and exploited, but the existence of a backdoor is not proof of a security flaw... and so far as I know nobody has traced Cowhand's presence back to anything but a social engineering or local (physical access, guessed passwords, etc...) attack.
I advise against buying antivirus software for the Mac. Antivirus software by its very nature can only reduce the reliability of your system, and since it's purely a responsive mechanism it can actually create a sense of complacency that makes viruses grow faster during the period before the virus is detected and a signature file is distributed.
Simply disabling any auto-execute mechanisms and being careful about who you share digital bodily fluids with works much better.
If the worst problem you can find in Mac OS X is that it allows social engineering attacks, well, that means it's even stronger than I'd give it credit for. Social engineering is not an exploit against the OS, it's an exploit against the user. You can't solve THAT technically, at least not until the Singularity when we can apply service packs on our neumonal implants.
Use a firewall, backup regularly, and don't open executables from untrusted sources. That's my whole regime.
Before 1997 that was good enough on Windows, too.
If you don't use Internet Explorer or any other application that uses the HTML control to access the Internet, that's probably STILL good enough on Windows. Be careful, because that means you don't use Realplayer, Windows Media Player, Outlook, and a lot of other applications as well as Internet Explorer.
Exploit, infections from not known:3 75,39155837,00.htm
http://news.zdnet.co.uk/internet/security/0,39020
This is to date the closest that Apple has come to the kind of horrorshow that Microsoft created back around 1997 when they integrated IE and Windows Explorer, and it's not very close at all. This hole could never be used to create an automatically propogating worm, the most it does is make social engineering attacks easier.
If social engineering was all we had to watch out for, like it pretty much was back in the early '90s when Microsoft turned the self-propogating email worm from a joke (the "GOOD TIMES" virus hoax) to reality, I'd be a happy camper.
Linux is a damned secure OS, at least as good as MacOS X.
Properly configured a Linux box, a BSD box, and a Mac should be comparably secure.
The problem is that you don't know what "Linux" a Linux is. Most Linux distributions I've used shipped with a lot of dubious software installed and enabled by default. Mac OS X isn't exactly at the level of paranoia of OpenBSD... not everything is turned off by default... but it comes with most of the "relatively paranoid security measures" already taken by Apple before they ship it.
GUI-level alerts like, "The file you're downloading contains a program, are you sure you want it?" and "This program is trying to launch for the first time, do you want it to?"
This is actually a step backwards in security. Internet Explorer on Windows now pops up some of the same dialogs, in many cases, and I have had several users come to me multiple times saying "I clicked on 'yes' accidentaly and now I think I have a virus"... because these dialogs come up often enough that people get trained into automatically clicking "yes". I've never had anyone come to me more than once with a story like "I downloaded a file, and then I opened it, and now I think I have a virus"... because downloading a file and opening it are sufficiently separate operations that you don't get trained into automatically clicking "open"... even in a download manager rather than on the desktop.
It would be much better for Safari to NOT automatically open downloaded files, and for LaunchServices to force applications that wanted to be treated as helpers for downloaded files to explicitly register as such, so that by default URLs like "x-man-page:" and "help:" would only be usable by applications directly rather than having the browser assume that any registered application was safe.
More important is that the browser has no built-in mechanism to perform unsafe actions, so it isn't possible to trick it into thinking a document is in a more trusted "zone" and automatically running it as a local user. The whole "security zone" model is so deeeply and fundamentally wrong that I'm still amazed Microsoft uses it.
But there is simply no suitable vector, akin to similar past (or present) vectors on Windows, for mass-propagation of any type of malware.
I think this is possibly exaggerating the case a little bit, because "social engineering" remains a vector... one that's disturbingly successful... and the way Safari interacts with LaunchServices by default makes social engineering easier than it should be. However, you're correct that there's no equivalent to Microsoft's security zone fiasco that makes automatic infection and mass-propogation of malware so easy on Windows.
If Mac OS X instead of Windows was the majority OS, the virus and worm problem would be no worse than it was in the early '90s before Microsoft integrated Internet Explorer with the Windows desktop and Outlook. Remember back when disabling any kind of mechanism to automatically open attachments or links, and not downloading pirated software, was usually good enough for avoiding infection?
OS9 was (and still is) a much more secure OS than OSX; it may well be amongst the most secure ever widely deployed by anyone.
Mac OS 9 has no local security at all: there's no mechanism in OS 9 to prevent any remote exploit from becoming a privileged exploit. How do you figure that it was "more secure" than OS X?