I have forgotten to update my virus software on OS X for months, with no ill-effect.
I agree that since it is certainly not in the “majority,” it’s not an attractive target to virus writers and hackers. Can’t say whether or not it’s programmed to be less vulerable, but I suspect that it probably is less vulnerable.
In general, UNIX-derived systems are more secure than Windows machines, because UNIX machines enforce more rules when it comes to running software.
For example, a program running under Mac OS X (derived from the BSD side of the UNIX family tree) cannot overwrite parts of an essential system file. Why not? Because the OS itself has decided that programs run by a normal user don’t have permission to modify files created by the administrator of the machine, commonly known as `root.’ Each file has some data associated with it, called permission bits, that tells the OS who has the ability to do what with it. Set the bits right, and normal users can’t even read the file.
Another strength of UNIX machines is how well they handle multiple programs running at the same time. A UNIX machine can, for example, decide that no program can use more than 25% of the CPU’s time. Because it can enforce such a rule, programs that depend on monopolizing a whole system simply break. They can be taken out and shot by any halfway-competent user.
Finally, the UNIX way of developing things like mailreaders and web browsers doesn’t allow for the kind of abuses people found in Visual Basic. There’s no simple way to get a program to execute arbitrary commands unless you can also crack the permission system. In general, UNIX programs are complex in different ways from their Windows bretheren, and those differences are important in this context.
As an added bonus, many UNIX applications are open-source. This means that their source code is available for wide review, giving many people a chance to fix bugs and close up security holes. Even if someone were to somehow sneak a questionable piece of code into an application, it would never get past the hundreds or thousands of other developers working on the project worldwide.
Here’s a little fact: Linux, a UNIX OS for PCs and other kinds of machines, has become the OS of choice for many servers and other Internet backbone applications, which would make it a juicy target for the crackers who wrote the Sobig.F worm. Yet one never hears of anything remotely like that hitting the Linux community. Therefore, relevant prevalence cannot be the determinant in how badly an OS is plagued by worms and viruses.
I’ll add to what AHunter3 said as well. Aside from having distinctions between different users and groups, Mac OS X (and Unix and Linux) have a concept of groups. So Chronos is right in that the first user is automatically added as an “administrator,” i.e., he’s added to the “wheel” group that has a certain set of rights. I’ll explain further:
Files and directories are “owned” by both a single user and a single group. This is easily expressed as “owner.group” in certain shell commands, and works for explanatory purposes, too. The owning user can do anything he wants to the file. A user that is in the owning group also can do anything he wants to the file. So a file owned by “balthisar.wheel” can be modified by me or by any other “wheel” group member (in the Mac GUI, “admin” users are assigned to “wheel”). It so happens that on Mac OS X, the group “wheel” is the owning group of a lot of files, which gives the original user and any other admin users the privileges to do a lot of stuff. Luckily, though, the important files are all owned by “root.system” and therefore even an admin user can’t touch them.
Just to be complete, files all have group Read/Write/Execute access for owners and group members and “anyone.” Therefore even if a file is owned by “root.system” a malicious root user can set file permissions to let anyone screw with system files or any file at all. Regular users can do this for their files, too, for example marking their ftp directory and files as readable for anyone. Or having a dropbox that’s only writeable.
It’s straight forward and makes a lot of sense once you’ve done it a few times.
Oh, one last thing – using “sudo” for a command pretty much negates the need to enable the root user. By default all “wheel” members are sudo-ers. I enable root, though, because it’s tiresome to type “sudo” all the time.
Standard Unix file security is actually rather crude compared to Windows NT/XP, not surprising since Unix was designed 20 years earlier than NT. In Windows you have much finer control over who can do what with a particular resource. You can set different file permissions for multiple users and groups, for example.
At least part of the blame for the blaster worm goes to lax sysadmins. MS released the patch that would’ve prevented it back in July, and the worm didn’t hit until August. If everyone were patching regularly, it wouldn’t have been an issue.
Maybe Microsoft should release their patches in the form of worms that propogate by exploiting the very security holes that they are patching over. The worm invades every PC with open ports, reaches out to any other computers it can find on the network once installed, and then patches the OS on the host box and gracefully erases itself.
Not quite correct. The rights for the owning user and the owning group are set completely independently, although it’s common to give the group full rights. And it’s possible for the owner to take rights away from himself (although he can give them back): This might be done to prevent accidentally overwrititng a file, for instance.
Anything that can be done with the Windows set of permissions can be done with the Unix set of permissions, though it might take a complicated set of user groups to do so. But while the Unix permissions can get complicated at times, the Windows permissions are always complicated, since there are so many potential settings which interact in so many ways.
Yeah, that’s correct. That’s why I went into read/write/execute for files. As the owner of a file (or in a group that owns a file) I can make a file not readable or writeable for myself. But since I own the file, I can set the permissions to anything I want and do anything I want to the file. Yeah, it’s an extra step, and keeps you from having to shout “D’oh!” 
Unless you mean something else, Chronos?
Also the rights are set compeletely differently; I guess I didn’t explain that really well. So my example “balthisar.wheel” means that there are two sets of permissions: one set for “balthisar” and one set for “wheel” members. My permissions may be RWX, while “wheel’s” may be --X (executable only).
Unix permissions can easily match XP permissions, but as Chronos said you sometimes have to be inventive with the groups.